Hi Jonah,
Yes, the I suppose the main problem is that p2 is allowing to install things that will simply not be possible to run after
the restart of Eclipse.
While the problem in p2 is not that obvious without big changes like the BREE change, the secondary problem is that the
org.eclipse.cdt-feature always adds the update site, and enables it. For downstream vendors, there is no way to deactivate the update site, or even remove it…
I understand that the CDT project want something like what is implemented, but at the same time, it causes a lot of problems
for downstream vendors/consumers. Is there any way the addition, or enablement, of the update site can be optional?
We’ve tried to use a feature patch in order to replace the p2.inf file, but it appears that a feature patch is not the antidote
here. For plugins, a simple fragment would have worked, but apparently not for features.
The product that we build should contain the
https://download.eclipse.org/release/2022-03 + our own update site.
In addition to these 2 update sites, the org.eclipse.cdt-feature adds the
https://download.eclipse.org/tools/cdt/releases/latest to the list, but as you said, there is no way to turn this off/remove it.
Kind regards,
Torbjörn
From: Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
Sent: den 21 december 2022 20:29
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Cc: Torbjorn SVENSSON <torbjorn.svensson@xxxxxx>
Subject: Re: [cdt-dev] Release of CDT 11.0 breaks product already released by downstream vendors
Hi Torbjörn,
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.
Hi list,
In ticket
https://bugs.eclipse.org/bugs/show_bug.cgi?id=575046, 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
https://download.eclipse.org/tools/cdt/releases/latest 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;
https://github.com/eclipse-cdt/cdt/issues/222).
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
https://download.eclipse.org/tools/cdt/releases/latest repository):
com.google.gson_2.9.1.v20220915-1632.jar
com.sun.xml.bind_2.3.3.v20221112-0806.jar
jakarta.xml.bind_2.3.3.v20221112-0806.jar
javax.activation_1.2.2.v20221112-0806.jar
javax.xml_1.4.1.v20220503-2331.jar
org.eclipse.launchbar.core_2.5.0.202211062329.jar
org.eclipse.tools.templates.core_1.3.0.202211062329.jar
org.eclipse.tools.templates.freemarker_1.3.0.202211062329.jar
org.eclipse.tools.templates.ui_1.4.0.202211062329.jar
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:
org.eclipse.cdt
org.eclipse.cdt.build.crossgcc
org.eclipse.cdt.debug.gdbjtag
org.eclipse.cdt.debug.ui.memory
org.eclipse.cdt.gdb
org.eclipse.cdt.gnu.build
org.eclipse.cdt.gnu.debug
org.eclipse.cdt.gnu.dsf
org.eclipse.cdt.launch.remote
org.eclipse.cdt.native
org.eclipse.cdt.platform
Kind regards,
Torbjörn
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
|
