search

eclipse-equinox / equinox.bundles

Eclipse Public License 2.0
8 stars 16 forks source link

Incorrect `org.osgi.service.prefs` dependency in org.eclipse.equinox.preferences-3.10.0 #54

Closed JohnLBergqvist closed 2 years ago

JohnLBergqvist commented 2 years ago

The declaration for the org.osgi.service.prefs dependency inside https://repo1.maven.org/maven2/org/eclipse/platform/org.eclipse.equinox.preferences/3.10.0/org.eclipse.equinox.preferences-3.10.0.pom

is wrong. Instead of being:

    <dependency>
      <groupId>org.osgi.service</groupId>
      <artifactId>org.osgi.service.prefs</artifactId>
      <version>[1.1.0,1.2.0)</version>
    </dependency>

as it currently is, it should be

    <dependency>
      <groupId>org.osgi</groupId>
      <artifactId>org.osgi.service.prefs</artifactId>
      <version>[1.1.0,1.2.0)</version>
    </dependency>

(basically, the <groupId> is wrong) as can be seen on Maven Central: https://search.maven.org/artifact/org.osgi/org.osgi.service.prefs/1.1.2/jar

Otherwise, I get a 

org.eclipse.platform:org.eclipse.equinox.preferences:jar:3.10.0 -> org.osgi.service:org.osgi.service.prefs:jar:[1.1.0,1.2.0): No versions available for org.osgi.service:org.osgi.service.prefs:jar:[1.1.0,1.2.0) within specified range

error. If I patch the POM file in my local maven cache, this problem is resolved and the dependency downloads as expected.

bjhargrave commented 2 years ago

So how is OSGi planning to address this mistake?

OSGi made no mistake. OSGi has only ever used the org.osgi groupId for specification artifacts.

This mistake is entirely in Equinox which mis-generated GAV values for the OSGi artifacts during its build. So the problem is Equinox's to solve.

jmini commented 2 years ago

Hopefully this incident demonstrates why it's a terrible idea to use floating dependency versions.

As I wrote on StackOverflow when you consume some dependencies using open version ranges, if you do not want to be disturbed by new releases (that can be corrupted as we saw today), you should fix/lock/control the versions you are using.

mickaelistria commented 2 years ago

The root cause of the issue is not OSGi but Eclipse Platform generating wrong groupIds. https://github.com/eclipse-platform/eclipse.platform.releng/issues/50 covers what Eclipse Platform needs to change to avoid this problem in the future. Please note that while it looks like a regression (X not working anymore), this issue is actually a consequence of a major improvement (Platform uses direct Maven artifacts without repackaging), which was not anticipated on some parts and thus causing temporary issues that are likely to have definitive fixes soon enough.

mdaloia commented 2 years ago

What is it weird is that Maven tries to resolve all the versions on the range even when it could use the latest one available that matches the range. That is the reason why releasing a 3.10.1 wasn't enough for many of us. Maven downloads the .pom of all the versions including 3.10.0 and 3.10.1 but it first attempts to do some processing of 3.10.0 and because it is flawed fails the build and doesn't care that there is a new version that it could use (the one that fixed that mistake).

The explained above could be seen for example with:

wget https://repo1.maven.org/maven2/org/eclipse/platform/org.eclipse.core.runtime/3.12.0/org.eclipse.core.runtime-3.12.0.pom
mvn -f org.eclipse.core.runtime-3.12.0.pom -Dmaven.repo.local=./temp-repo dependency:tree

Tested with 3.8.6

org.eclipse.core.runtime-3.12.0.pom has this dependency and version range:

<dependency>
    <groupId>org.eclipse.platform</groupId>
    <artifactId>org.eclipse.equinox.preferences</artifactId>
    <version>[3.4.0,4.0.0)</version>
</dependency>

Currently all the versions published on Maven Central matches that range...

versions on Maven Central

... so Maven downloads them all (just the pom... when a version is selected then that jar is downloaded).

versions download to local repository

After it fails, if you locally change what was wrong:

sed -i '' -e 's#<groupId>org.osgi.service</groupId>#<groupId>org.osgi</groupId>#g' ./temp-repo/org/eclipse/platform/org.eclipse.equinox.preferences/3.10.0/org.eclipse.equinox.preferences-3.10.0.pom

The build ends successfully.

Maybe there is an explanation of why Maven behave this way when ranges are used... or maybe it is a bug that didn't come up until now with this combination of factors.

So based on that, I think that to in order to transparently fix the issue for transitive consumers (i.e. not having everyone to modify build config that was working until now) would be one of 2 things:

laeubi commented 2 years ago

What is it weird is that Maven tries to resolve all the versions on the range even when it could use the latest one available that matches the range.

No this is not weird, this is required because maven could *not just use the latest version, that's not what version ranges are for, this is especially to allow a lower version e.g. because of conflicts with other (transitive) dependencies or ones in your module, because of that maven first needs all the poms and all the transitive dependencies.

Maybe there is an explanation of why Maven behave this way when ranges are used... or maybe it is a bug that didn't come up until now with this combination of factors.

As mentioned above, it might be god to create an enhancement request for maven to not fail completely but warn (as it does on other places, e.g. when it can't find the pom at all!).

but it is causing a lot of pain for end users

no pain no gain! :-)

sravanlakkimsetti commented 2 years ago

Raised https://issues.sonatype.org/browse/OSSRH-81766 to get offending artifacts removed. Lets wait for maven central to act there

tombrus commented 2 years ago

I hope you will be able to quickly release a fixed version. Thanks for all the open-source effort! I thought I'll share my workaround:

You can patch your local .m2 cache with the following command (bash):

cp -r .m2/org/osgi/org.osgi.service.prefs/* .m2/org/osgi/service/org.osgi.service.prefs/

downside: it only works until you clean your .m2 cache! (but you can redo it or even script it) upside: you do not need to think about removing it when a fixed version is published, nothing permanent is changed!

...and yes, if you have a zillion machines around it is not very practical to do it by hand... but you can script it... or make a cron job 😆 be creative!

PranavPurwar commented 2 years ago

The fixed version was already released yesterday @tombrus

bjhargrave commented 2 years ago

org.eclipse.core.runtime-3.12.0.pom has this dependency and version range:

<dependency>
    <groupId>org.eclipse.platform</groupId>
    <artifactId>org.eclipse.equinox.preferences</artifactId>
    <version>[3.4.0,4.0.0)</version>
</dependency>

I will note that whatever code is generating the maven version range is generating a too-broad range. In the above example, the range includes 4.0.0-M1 and other pre-final qualifiers on version 4.0.0. The correct maven version range is [3.4.0,4.0.0-alpha) as that will include no version which starts with 4.

sravanlakkimsetti commented 2 years ago

Raised https://issues.sonatype.org/browse/OSSRH-81766 to get offending artifacts removed. Lets wait for maven central to act there

the offending artifacts have been removed from maven central. Please try now

adebiasi commented 2 years ago

Now I have the following error: Error injecting constructor, com.google.inject.internal.util.$ComputationException: com.google.inject.internal.util.$ComputationException: java.lang.UnsupportedClassVersionError: org/eclipse/core/runtime/OperationCanceledException has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

akurtakov commented 2 years ago

Java SE 11 = class file version 55 . o.e.core.runtime bundle requires it since September 2021 release https://github.com/eclipse-platform/eclipse.platform.runtime/commit/74823fe0fcfe5f76baff2c29c93f0d8dbd9bcfe8

adebiasi commented 2 years ago

Why this error didn't appear before the artifact's fix?

cdietrich commented 2 years ago

@adebiasi can you provide a minimal reproducer

akurtakov commented 2 years ago

Why this error didn't appear before the artifact's fix?

This I can not even try to answer without reproducer and/or link to logs. Also please move to new issue for that.

adebiasi commented 2 years ago

Why this error didn't appear before the artifact's fix?

This I can not even try to answer without reproducer and/or link to logs. Also please move to new issue for that.

I created https://github.com/eclipse-equinox/equinox.bundles/issues/61.

laeubi commented 2 years ago

Platform requires java 11, so actually there is no "issue" and you probably have not seen it before because now the dependency has changed, the build was adjusted, using never java features of changed BREE, ...

If you require "old" behavior you have to use the old release...

Borki commented 2 years ago

Can you let remove the wrong version also from JCenter: https://mvnrepository.com/artifact/org.eclipse.platform/org.eclipse.equinox.preferences

On maven central it's already removed.