Old and outdated 3rd party libraries

[jukzi]

Eclipse IDE is installed with some libraries that are several years old:

that may not be a problem by now, but it indicates, that we are probably not using the latest version of the libraries which may make an update hard if needed.
For example org.apache.commons.logging has released a newer 1.3.0 November 2023
https://commons.apache.org/proper/commons-logging/

[laeubi]

Can you tell where platform is using org.apache.commons.logging?

Beside that, just because the signature is old does not mean thre is any issue, e.g. all the mentioned (OSGi) APIs are likely won't change because their API is stable.

[mickaelistria]

This bundle is not coming from Platform. See https://download.eclipse.org/eclipse/updates/4.32-I-builds/I20240310-1800/plugins/ , Platform contains 1.3.0 as distributed in Maven Central.

[merks]

Yes, I see very little (if anything) here that looks like there would be newer versions. Some things are just very stable. For anything the platform pulls from Orbit, EMF, or ECF are definitely thee are latest available.

Orbit itself generates target platforms to find the latest of anything so all these update sites are the latest:

https://download.eclipse.org/tools/orbit/simrel/

Orbit also analyzes the target platforms of projects showing any updates available, including doing that for the Platform:

https://github.com/eclipse-orbit/orbit-simrel/blob/main/report/maven-osgi/platform/REPORT.md

Given this is an issue for the Platform, it should only consider what's actually in the Platform SDK, not what additional tools are installed for Platform development purposes. That involves installing quite a few extra things, including parts of Mylyn, WTP, and so on...

I believe the only potential source of actual outdated dependencies that would come from dependencies pulled in by (or restricted by) ECF. It is on my TODO list to update ECF itself to use the latest Orbit releases for its target platform and I've already started prototyping that a few months ago; breaking APIs in some dependency made this a challenge because I don't know the ECF code and I don't know the APIs of the 3rd party libraries being used. EMF has no third party dependencies, so that's not an issue. And, ad I said, the Platform pulls from Orbit or directly from Maven; in both cases those things are automatically updated as updates become available.

[laeubi]

Most of the time "old" stuff is pulled in because features explicitly listing their third party dependencies, so P2 is forced to include this specific library version.

[merks]

Or with version range constraints. Here we see both in action:

Usually narrow version ranges are a result of the fact that the bundle supplier tends to break API making the consumer overly cautious...

[laeubi]

Yes but version constraints are something that might work for a range where the feature one will even probably pull in v1.1, v1.2 and v1.3 then, so I think one first should target features and then ranges :-)

[merks]

Yes, I believe we've established that in general one should include bundles and features in one's own features if and only if those bundles and features are your own bundles and features, not ones from upstream dependencies, including not ones from upstream 3rd part dependencies. But getting folks to listen and furthermore getting them to do the actual work is another thing entirely, with ECF being the relevant example here. And of course I mention the case here because I'm relatively certainly 1.3.0 is being excluded because of that highlighted version range.

[jukzi]

This bundle is not coming from Platform

I have installed a fresh Eclipse Development Environment as explained on https://github.com/eclipse-platform/.github/blob/main/CONTRIBUTING.md (i.e. OOmphed)
It installed the org.apache.commons.logging_1.2.0.v20180409-1502.jar as seen in screenshot

[mickaelistria]

I have installed a fresh Eclipse Development Environment as explained on https://github.com/eclipse-platform/.github/blob/main/CONTRIBUTING.md (i.e. OOmphed)

Then it's an issue with Oomph configuration. As shown in the p2 repo which is the main deliverable of Platform/SDK, the artifact is not present. You may also want to verify in the archived products if you want.

[merks]

@jukzi

Please read #190 (comment) and #190 (comment) carefully and ask for clarification if there is something you did not fully understand. As I said, additional tools are installed for development purposes WebTools, M2E, EMF's generator, and so on. These all impact what's installed and impact which 2rd party library make all these bundles happy, but that's different than asking what is in the SDK that's being shipped by the Platform.

[merks]

BTW, I investigate a bit more and it's Oomph's fault for using the older BSN. Here's the technique/trick to find out why an IU is present. Add a negative IU requirement to any p2 task on any of the setups:

You have to unfilter the advanced properties and can set min and max to 0.

Then when you do Perform Setup Tasks, p2 will explain why the resolution fails:

  at org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:721)
  at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
  ERROR: org.eclipse.equinox.p2.director code=0 Software being installed: artificial_root 1.0.0.v1710329911267
  ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency:
    ERROR: org.eclipse.equinox.p2.director code=0 From: artificial_root 1.0.0.v1710329911267
    ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; org.apache.commons.logging 0.0.0, min=0, max=0
  ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency:
    ERROR: org.eclipse.equinox.p2.director code=0 From: artificial_root 1.0.0.v1710329911267
    ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; org.eclipse.oomph.setup.feature.group 0.0.0
  ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency:
    ERROR: org.eclipse.equinox.p2.director code=0 From: Oomph Setup Core 1.30.0.v20240211-0940 (org.eclipse.oomph.setup.core.feature.group 1.30.0.v20240211-0940)
    ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; org.eclipse.oomph.setup.sync [1.16.0.v20240211-0940,1.16.0.v20240211-0940]
  ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency:
    ERROR: org.eclipse.equinox.p2.director code=0 From: Oomph Setup 1.31.0.v20240306-1109 (org.eclipse.oomph.setup.feature.group 1.31.0.v20240306-1109)
    ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; org.eclipse.oomph.setup.core.feature.group [1.30.0.v20240211-0940,1.30.0.v20240211-0940]
  ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency:
    ERROR: org.eclipse.equinox.p2.director code=0 From: Oomph Setup Synchronizer 1.16.0.v20240211-0940 (org.eclipse.oomph.setup.sync 1.16.0.v20240211-0940)
    ERROR: org.eclipse.equinox.p2.director code=0 To: osgi.bundle; org.apache.commons.logging [1.0.0,2.0.0)

Of course I will rectify that in Oomph!

[Bananeweizen]

To add to Ed's debugging tips: I often use the plugin explorer from Andrey to find similar (unwanted) relations in targets: https://github.com/iloveeclipse/plugindependencies. This is what it shows when using "running platform" as the target platform to analyze, filtering on the above mentioned commons.logging: