Maven export should use fixed ranges

[kenwenzel]

The issue is transferred from here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=578085

The deployment of org.eclipse.jdt:org.eclipse.jdt.core:XXXX on Maven uses version ranges to specify its dependencies e.g. org.eclipse.platform:org.eclipse.text:[3.6.0,4.0.0)

The problem with this is that it's too open ended and when trying to retrieve the last version that supported jdk8 (version 3.25.0), the transitive dependencies bring in versions that are compiled for jdk11 e.g. org.eclipse.platform:org.eclipse.text last jdk8 version was 3.9.0 but version 3.12.0 is chosen which compiles to jdk11 so can't be used.

I can see this being an issue in the future on the switch from jdk11 -> 17.

So would it be possible to change to using strict dependency version numbers in the pom.xml deployed to Maven instead of ranges. Currently to get the jdk8 version working I have to specify all the transitive dependencies manually.

All the transitive dependencies that bring in more dependencies also use ranges...
org.eclipse.jdt:org.eclipse.jdt.core
org.eclipse.platform:org.eclipse.ant.core
org.eclipse.platform:org.eclipse.compare.core
org.eclipse.platform:org.eclipse.core.commands
org.eclipse.platform:org.eclipse.core.contenttype
org.eclipse.platform:org.eclipse.core.expressions
org.eclipse.platform:org.eclipse.core.filesystem
org.eclipse.platform:org.eclipse.core.jobs
org.eclipse.platform:org.eclipse.core.resources
org.eclipse.platform:org.eclipse.core.runtime
org.eclipse.platform:org.eclipse.core.variables
org.eclipse.platform:org.eclipse.equinox.app
org.eclipse.platform:org.eclipse.equinox.common
org.eclipse.platform:org.eclipse.equinox.preferences
org.eclipse.platform:org.eclipse.equinox.registry
org.eclipse.platform:org.eclipse.osgi
org.eclipse.platform:org.eclipse.team.core
org.eclipse.platform:org.eclipse.text

[kenwenzel]

This is really a severe problem that we are facing in many of our projects.
It is nearly impossible to create reproducible builds using the Eclipse Platform Maven artifacts.

The first part of the solution would be to use FIXED versions in Maven dependencies. Using version ranges in Maven are commonly considered as bad practice: https://www.reddit.com/r/Maven/comments/vkcmys/why_maven_doesnt_have_a_lock_file_like/

The second part of the solution would be to create a Maven BOM for a group of related Eclipse modules:
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms

This would ensure that only Eclipse modules are used together that are compatible.

[laeubi]

@merks I though it was already changed to not use ranges last release but also noticed that today with another artifact that there are still some ranges.

[kenwenzel]

@laeubi Maybe you could also try to provide BOMs for all the releases that already exist on Maven central? This would help to somehow fix also the already existing artifacts.

[merks]

This issue doesn't state which version is involved, but I don't think it applies to the latest release, e.g.,

https://repo1.maven.org/maven2/org/eclipse/jdt/org.eclipse.jdt.core/3.34.0/org.eclipse.jdt.core-3.34.0.pom
https://repo1.maven.org/maven2/org/eclipse/platform/org.eclipse.ant.core/3.7.0/org.eclipse.ant.core-3.7.0.pom

We do now actually test that every artifact resolves and I believe none of our dependency mapping rules map to ranges:

[kenwenzel]

For example version 3.19.100 of org.eclipse.ui.ide had this issue:
https://central.sonatype.com/artifact/org.eclipse.platform/org.eclipse.ui.ide/3.19.100/overview

But it seems to be fixed now.

@merks Do you think it is possible to generate BOMs also for older versions? This would not change the existing dependencies but would help to consume the existing versions correctly.

[merks]

Yes we spent quite some effort during previous releases to ensure that what's published to Maven is correct before we published and to ensure it's consumable, i.e., generate a dependency version based on what's current being being used/resolve for that dependency.

I don't actually know what a BOM is. Of course I know it stands for Bill Of Materials, but I don't know anything about it beyond that term. So I don't know how we would generate one nor how we'd do that for previous releases. It might well not be hard and it might well be possible because these things are generated from the contents of the Platform's release repository.

But in the end, it sounds like more work and I'm personally beyond swamped. So the people who want it will probably need to get involved in helping produce it and even then, reviews will still be needed and then long term someone needs to support yet something else new forever...

[kenwenzel]

Thank you @laeubi and @merks for fixing this in the latest releases.