Generate pom files with actual versions for deps instead of ranges

[mickaelistria]

Maven is not as good as p2 or OSGi with dependency ranges; moreover, unlike p2 repo where we can have a consistent subset of all possible artifacts that are known to work well together, a Maven repository such as Central is accumulative and keeps older versions or future ones just as accessible as whatever version the artifact was tested against.
Overall, usage of version ranges in Maven is unfortunately too risky for general usage; we should instead prefer publishing pom files specific artifact versions. This will make consumption via Maven work better in general, without preventing people from binding to different versions explicitly if they want/need to.

[laeubi]

@mickaelistria to be fair its not really maven to blame here. The P2 approach only "works" because we have one repository per release, what on the other hand massively duplicates content. If we would have had only one repository for all, the same problems would arise.

The real problem is that most platform bundles simply claim they are compatible with whatever will be there in the future and no one care to set valid ranges.

Beside that I think @merks has already adjusted the pom generator to account for this in #119

[merks]

I'm not sure exactly what's being proposed here. Are you suggesting the specified OSGi lower bound be adjusted when mapped to Maven dependencies to match the exact current actual version? It seems to me that makes the artifacts less reusable. Moreover, it seems to me that if this is desired in general (this being ensuring that a known-to-work -well-together set of things are resolved/installed), it should (also/instead) be done in OSGi which is massively consumed downstream where works-well-together is also super important. I.e., it seems to me the real problem is bogus version ranges in the bundles and we'd best fix those.

@cdietrich Would changes such as what I think is proposed here have any impact on Xtext published Maven artifacts?

[cdietrich]

For ancient versions maybe (they are broken anyway and need Version overrides in maven and gradle anyway) . For recent we have a maven bom where we (try to) pin all platform dependencies so it should be no issue
If open upper ranges stay, then of course we have to continue so
https://github.com/eclipse/xtext-lib/blob/b4fe1aa69e17a35542d0f429847a7cfd07608012/org.eclipse.xtext.dev-bom/build.gradle#L59

[laeubi]

For recent we have a maven bom where we (try to) pin all platform dependencies so it should be no issue

Well that actually is the issue, having dependencies in the pom, where consumers need to "pin versions" for each to get it working is completely useless.

So yes, any "OSGi bound" should be ignored and one must use the version that is used in the actual update-site.

[mickaelistria]

I'm not sure exactly what's being proposed here. Are you suggesting the specified OSGi lower bound be adjusted when mapped to Maven dependencies to match the exact current actual version?

I'm suggesting that instead of generating a range in the pom.xml, we just set the artifact version that we've built/resolved against in the current p2 repo. Eg in https://repo.maven.apache.org/maven2/org/eclipse/platform/org.eclipse.ui.workbench/3.126.0/org.eclipse.ui.workbench-3.126.0.pom , the blocks like

<dependency>
  <groupId>org.eclipse.platform</groupId>
  <artifactId>org.eclipse.swt</artifactId>
  <version>[3.107.0,4.0.0)</version>
  <optional>false</optional>
</dependency>

would be replaced by

<dependency>
  <groupId>org.eclipse.platform</groupId>
  <artifactId>org.eclipse.swt</artifactId>
  <version>3.121.0</version>
  <optional>false</optional>
</dependency>

Because it's the one we resolved/built against and thus we know is compatible.

@laeubi is right, the issue is not Maven, but more the fact that we don't apply fully semantic versioning, particularly for internal packages, so we do not guarantee compatibility with ranges and a random assembly of mulitple bundles from multiple Eclipse Platform releases is more likely to fail than to succeed.

[merks]

So you'd like it to look like this:

I thought I'd have to implement something new in the aggregator, but the rules for mapping dependencies, currently used only for mapping java.package dependencies, can be more generally applied accomplish this effect...

[mickaelistria]

So you'd like it to look like this

Yes.

I thought I'd have to implement something new in the aggregator, but the rules for mapping dependencies, currently used only for mapping java.package dependencies, can be more generally applied accomplish this effect...

Interesting. I'll also be looking at it for a couple of days.

[merks]

One word of caution here though, if this is generally applied then the dependencies on EMF and ECF assume that the versions of EMF and ECF that you use are also published to Maven.

Certainly EMF publishes to Maven in advance of the Platform doing so.

@scottslewis I assume that for any version of ECF contributed to the Platform/SimRel is also published to Maven. Is that a safe assumption?

@mickaelistria As I look further into this just now, I think this will be problematic if you want to publish snapshots because EMF does not publish snapshots and I doubt ECF does either.

[mickaelistria]

I'm closing this one as the main work is done, and will open another ticket about a current bug with SNAPSHOT

[scottslewis]

One word of caution here though, if this is generally applied then the dependencies on EMF and ECF assume that the versions of EMF and ECF that you use are also published to Maven.

Certainly EMF publishes to Maven in advance of the Platform doing so.

@scottslewis I assume that for any version of ECF contributed to the Platform/SimRel is also published to Maven. Is that a safe assumption?

In general yes, but there may be an ordering problem as generally we publish releases to Maven after making contributions to platform. Does this have to change?

@mickaelistria As I look further into this just now, I think this will be problematic if you want to publish snapshots because EMF does not publish snapshots and I doubt ECF does either.

No we do not publish snapshots either.

[merks]

@scottslewis As long as you publish whatever you contributed to the Platform/SimRel before the date the platform publishes its maven build all would be great. Moreover, I added special support so that EMF and ECF's version range dependencies are respected so unless the platform moves the range up to the newly-contributed version and you publish your release after the platform publishes all should be fine.