Please build with the latest Orbit versions

[merks]

The feature include of an old version of Guava is leading to duplication:

And worse still, this Guava bundle is treated as unsigned by the latest LTS versions of Java.

Here's a report for your specific repository:

https://download.eclipse.org/oomph/archive/reports-extra/rcptt/download.eclipse.org/rcptt/release/2.5.4/repository/index.html

I suggest using this repository for your build to make these two problems go away.

https://download.eclipse.org/tools/orbit/downloads/2022-12/compositeContent.xml

Thanks in advance!

[basilevs]

This may break support for older AUTs, but that's acceptable at this point.

[merks]

Note that Orbit is actively removing wrapped bundles which already come as OSGi artifacts so they are expecting you to either use m2e maven locations in your target platform or you could consume such things already PGP-signed from here:

https://download.eclipse.org/oomph/simrel-maven/2023-09

We're also planning on moving this to the Orbit project eventually...

[merks]

It would be awfully nice to avoid versions of guava with CVEs:

https://www.cvedetails.com/cve/CVE-2023-2976/

It would also be great to avoid this duplicate:

[HannesWell]

I can only second that it would be great to allow more recent versions of guava.

This may break support for older AUTs, but that's acceptable at this point.

You don't necessarily have to break users. What would already help is to remove guava from your features to not lock the version, then you should not require the guava bundles but instead import the com.google.common.* packages with a version range that starts at the lowest version you support (in your case probably 27?), and has a upper bound that includes the recent versions. If you only use stable APIs that are probably not removed, it would probably be fine to leave the upper bound open and just specify the lower bound.
This way rcptt can be used with any Guava version from 27 onwards (or what lower bound you choose) and SimRel can finally get rid of Guava 27.

[merks]

FYI, hear is another example of the real problems such duplicates cause:

eclipse-equinox/equinox#304

[basilevs]

I can only second that it would be great to allow more recent versions of guava.

This may break support for older AUTs, but that's acceptable at this point.

You don't necessarily have to break users. What would already help is to remove guava from your features to not lock the version, then you should not require the guava bundles but instead import the com.google.common.* packages with a version range that starts at the lowest version you support (in your case probably 27?), and has a upper bound that includes the recent versions. If you only use stable APIs that are probably not removed, it would probably be fine to leave the upper bound open and just specify the lower bound. This way rcptt can be used with any Guava version from 27 onwards (or what lower bound you choose) and SimRel can finally get rid of Guava 27.

This approach fails to work in AUT's which do not have any Guava installed.

[merks]

Sorry if I'm being dense, but what is an AUT? Automated Unit Tests What exactly is it that fails? I'm confused because if any bundle requires Guava then Guava will be installed regardless of whether some feature includes it or not, but maybe I'm missing some context. The Platform itself has been removing 3rd party includes from features for quite some time now. Maybe replacing the bundle include with a bundle import with only a lower bound would also work without breaking anything...

[basilevs]

Sorry if I'm being dense, but what is an AUT? Automated Unit Tests What exactly is it that fails? I'm confused because if any bundle requires Guava then Guava will be installed regardless of whether some feature includes it or not, but maybe I'm missing some context. The Platform itself has been removing 3rd party includes from features for quite some time now. Maybe replacing the bundle include with a bundle import with only a lower bound would also work without breaking anything...

AUT = Application Under Test
Installation of Guava is not a given - if AUT does not contain Guava, RCPTT runtime has to inject it along with its runtime (because runtime depends on Guava). For runtime to be compatible with RCPTT IDE, IDE uses same version of Guava as runtime. Runtime has to depend on old version of Guava, because it has to run in Eclipse Kepler and Eclipse Mars, so this defines the version of Guava RCPTT IDE uses and is allowed to depend on.

AFAIK, Platform did not depend on Guava in the first place (RCPTT had to take it from Orbit explicitly, so it was never present in platform releases). Even if Platform does not depend on Guava, this does not help, as custom AUTs do and can contain very old versions, that RCPTT has to be compatible with.

Do not use imports, they cause false negatives in design time dependency loop detection, which is fatal for lazy-activated bundles (although, as Guava does not need activation, in this particular case we could theoretically afford an Import-Package, Guava being a guaranteed dependency leaf also helps).

Even if dependency restriction is relaxed (Import or Require), in AUTs without Guava RCPTT runtime will have to carry its own copy of Guava bundle with version restrictions explained above.

Anyway, with RCPTT shorthanded, the drop of support of old versions of Eclipse as AUT is inevitable, and this issue is just another reason to do so. This will happen eventually, but at the moment, all available resources are bound by support of recent Eclipse release.

[merks]

I can relate to wanting to keep things as compatible as possible. I do that with EMF as well and actually test that it runs with kepler:

https://ci.eclipse.org/emf/job/all-target-platforms/

And I'm the only person who maintains EMF and does the builds...

I do see really old versions of guava in kepler/mars

This is the first release where I see 27.x in the repo:

As far as SimRel is concerned, the upper bounds on Guava in these two features is the only problem:

The later looks to be from an import rather than an include and I see there are both:

https://github.com/eclipse/org.eclipse.rcptt/blob/1c135e41961a5563abc36181ecdfad5462e7edce/launching/org.eclipse.rcptt.launching-feature/feature.xml#L30C14-L31C78

org.eclipse.rcptt/launching/org.eclipse.rcptt.launching-feature/feature.xml

Lines 114 to 119 in 1c135e4

	<plugin
	id="com.google.guava"
	download-size="0"
	install-size="0"
	version="0.0.0"
	unpack="false"/>

The import was changed not that long ago:

[basilevs]

I can't remember why I did that change.
A version of Guava has introduced a backward incompatible change, that required some plugins using old version to set upper-bound in manifests. However the change you quote does not seem to be caused by this (I would usually change MANIFEST.MF, not feature.xml for that).
I don't remember what was going on there, so we can try to remove that one line and see what happens.

[merks]

Removing the include and changing the import match to greaterOrEqual would be better for SimRel...

[basilevs]

Why do you think removal of include will work? Does platform depend on Guava now? This feature does need some Guava.

[merks]

In the "SimRel Recommendations" section of https://github.com/orgs/eclipse-orbit/discussions/49 it has been recommended (and previously discussed with multiple participants) to avoid includes 3rd party dependencies in features that are contributed to SimRel.

I would ask the question in the opposite way. Why do you think inclusion is strictly necessary to make something work? It might be better to try without it because that will avoid me showing up here every 3 months complaining about the old version of guava that rcptt strictly and exclusively requires (and the about CVEs the old required thing, which is current already the case)...

[basilevs]

Sorry, I do not understand how to make a self-sufficient feature without including the required plugin. Do you want me to create a side-car feature and omit it from SimRel?

[basilevs]

We include Guava here because when we removed it years ago, our IDE product would not build and install from update site would fail.

[merks]

Indeed one of the reasons folks often use includes is to ensure that the bundle ends up in their update site. But you can mention the bundle directly in the category.xml instead. Or, alternatively, you can define a "3rd party dependencies" feature (side-car feature if you to call it that), and that in turn is included in the category.xml. Definitely you do not want guava to suddenly be missing from your update site!!

[merks]

I took the approach of adding a feature when I reworked datatools

https://github.com/eclipse-datatools/datatools/blob/master/features/org.eclipse.datatools.dependencies.feature/feature.xml

https://github.com/eclipse-datatools/datatools/blob/db2cc047b366af4ef43a55c94ff1ec4afabd0cc6/site/category.xml#L204-L206

I took this approach because that way there is only one additional thing listed as a root element in the site, rather than a bunch of 3rd party bundles. And I did this also so that I don't need to keep providing updated datatools builds that effectively only update the dependencies...

[merks]

RCPTT is not actively participating in SimRel. The reports I'm prototyping indicate the content is more than 400 days old:

https://github.com/merks/test/blob/master/report.md#-rcptt

Looking at the project portal:

https://projects.eclipse.org/projects/technology.rcptt

the project has not done a reviewed release since the start of 2020, so RCPTT isn't even properly following the Eclipse Development Process.

During the next release cycle I will remove projects that are not actively participating and/or those projects not actively keeping their dependencies up-to-date.

https://github.com/eclipse-simrel/.github/blob/main/wiki/SimRel/Simultaneous_Release_Requirements.md#re-use-and-share-common-third-party-code-partially-tested

I thought it best to warn you well in advance so that you can you can do something about it well in advance. I don't want you to be surprised when I disable RCPTT's contribution in January.

/cc @jonahgraham

[basilevs]

@merks thanks! No resources for release management here.

[benken-parasoft]

I just wanted to share some feedback based on my own observations and experience.

The p2 repositories for the latest Orbit can now be found here:
https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/release/

Orbit now has latest third party bundles, many of which are now exactly the same as what you would find on Maven Central.

For one of my projects, I have a feature with only my bundles. The p2 I assemble includes my feature and all my bundles. I include third party bundles in my p2 as well but they are uncategorized and not part of my feature. They are only there in case the user's Eclipse installation is missing them and are not part of my feature. Eclipse will happily resolve them from the p2 but only as needed.

I decided not to define something like a "3rd party dependencies" feature. Instead, my third party dependencies are not part of a feature and are uncategorized in the p2. How to accomplish this is not obvious but I found a trick. tycho-p2-publisher-plugin runs "publish-categories" to publish categorized features and bundles referenced in a category.xml. However, it also runs "publish-products" to publish uncategorized stuff from a ".product" file. I never call "tycho-p2-director:materialize-products" because I am not actually assembling an Eclipse product. I only use a ".product" file as a trick to include uncategorized third party bundles that are not and should not be part of the feature containing my bundles.

[basilevs]

Guava 31 is now used for RCPTT IDE. Runtime versions are hopefully unaffected.