Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Release of CDT 11.0 breaks product already released by downstream vendors

Hi Torbjörn,

I think is a partial discussion on this.

To me there are two issues here:

1- p2 is making a mistake considering versions of bundles that depend on Java 17 when no Java 17 is available. This should be reported/fixed in equinox/p2.

2- You are shipping a product with enabled. Eclipse EPP ships products with which would have the same problem. Presumably you don't have in your available p2 sites? For this issue, is the problem that you can't remove from available p2 sites in your product? 


Jonah Graham
Kichwa Coders

On Wed, 14 Dec 2022 at 13:40, Torbjorn SVENSSON via cdt-dev <cdt-dev@xxxxxxxxxxx> wrote:
Hi list,

In ticket, we switched for explicit versions in the update site URL to the more generic "latest".
While you wouldn't notice too much difference as long as it's the same BREE of the 2 versions (your current installed version and the latest CDT release), it does make a big difference when the BREE is newer than the JRE used.

As part of the CDT 11.0 release, the latest update site was repointed to the ../cdt-11.0/ sub-repository.
This works fine for product that already rely on a JAVA17 compatible JRE, but for those that are stuck on a JAVA11 JRE, this will break the Eclipse environment, as some of the plugins might be fetched from this newly released version of CDT rather than from the SimRel repository that is also defined in the installation.

An example of the problem would be to have a product based on the 2022-03 SimRel with the core CDT parts included. In the product, the CDT features are version locked in the product definition. The product is also shipped using a JAVA11 JRE with no option to switch to JustJ 17 or similar.
In this product, you install one of the optional CDT features.
>From my point of view, the optional feature (and plugins) should be fetched from the 2022-03 SimRel repository as they are the only one available that are compatible with the JRE11 that is used.
What will really happen is that part of the update will be fetched from that happens to be CDT11 right now, and part will be fetched for 2022-03 SimRel.

An example of the problem would be to download the 2022-03 SimRel, replace the included JustJ with a JRE11 instance and then try to install any feature from CDT that is not installed by default. It's likely that this new feature (I would expect it to be fetched from the 2022-03 SimRel repository, as that's the only compatible feature available) would actually be fetched from CDT11 and you would have a mix of JAVA11 and JAVA17 plugins. There would be no indication that this would be a problem and if you have some other feature that is blocking the entire CDT to be upgraded, you could be even more confused as the CDT release does not appear to have a feature for all plugins (so they can't even be version locked;

In the product I'm working on, we have locked the CDT version, but even after locking everything we depend on from CDT (feature based lock), we still end up with a situation that the following plugins are fetched from CDT 11.0 (though the repository):

Some of theses plugins are fine to run in a JAVA11 JRE, but others are not.
After installing a simple extra feature in our product (that has nothing to do with CDT itself), the entire CDT refuses to load due to that one or more of the listed plugins have BREE=17.

So, to avoid this mess, I see a few possibilities.

1. Do not advertise anything under the "latest" repository to avoid breaking 3rd party products.
2. Respin the CDT 10.6 and 10.7 releases to not use to the "latest" update site.

If you have any other suggestions on how to resolve this, please let me know.

For completeness; the CDT provided features that our product has locked down are:

Kind regards,
cdt-dev mailing list
To unsubscribe from this list, visit

Back to the top