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

[JohnLBergqvist]

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.

[HannesWell]

Thank you for your report.
The pom-file is generated during the release process (at least org.eclipse.equinox.preferences has none in git) and it looks like this generation is flawed.
@akurtakov or @mickaelistria can you help here or know who can do better?

[ghost]

We have the same issue today, the whole CI pipeline is broken because the group Id isn't existed. The current workaround is creating the folder structure as same as the wrong group Id and throwing the jar to there.

[akurtakov]

@sravanlakkimsetti You're the best person to help here. What/where/how generates the pom files deployed?

[cdietrich]

i also wonder if we can create a new repo in eclipses nexus where some milestones or nightlies for these and also platform and jdt maven artifacts can be published. e.g. xtext could use these in their integ tests so that problems like this one are detected earlier

[laeubi]

i also wonder if we can create a new repo in eclipses nexus

Why a new repo? Is the existing one not sufficient?

where some milestones or nightlies for these and also platform and jdt maven artifacts can be published. e.g. xtext could use these in their integ tests so that problems like this one are detected earlier

The problem is that current maven deployment is a nasty script witch need manual execution... One the equinox repos are merged I plan to try setup a more automated flow for the equinox that could be used as a basis for other repos as well.

[cdietrich]

when broken milestones are published to a release repo, then of course the "maven central" is broken problem would turn into the "eclipse release repo is broken"

[laeubi]

At least in tycho, staging or milestone repos has been proven to produce more hassle than they solve.

If we publish something "broken" we simply should fix that and publish a new version immediately.

[akurtakov]

repo.eclipse.org can be used to deploy SNAPSHOT versions and only builds that explicitly enable it will use them. We do that with Tycho and it works well sothere is no need for new repo.
It's entirely separate question the effort to setup/automate that publishiing .

[sravanlakkimsetti]

I am trying a solution for this one. It will take some time. but hopefully by today or tomorrow I will be able to fix this one

[castielfang]

firstly maybe you should remove the version 3.10.0 from repository,stop to effect the more users

[akurtakov]

Can you actually remove things from Maven Central? I thought this is a not allowed.

[laeubi]

Can you actually remove things from Maven Central? I thought this is a not allowed.

https://stackoverflow.com/questions/9789611/removing-an-artifact-from-maven-central

You can only contact the support, but as no one is forced to upgrade their pom, you can simply use the old version in the meanwhile...

[kesslerd]

Can you actually remove things from Maven Central? I thought this is a not allowed.

https://stackoverflow.com/questions/9789611/removing-an-artifact-from-maven-central

You can only contact the support, but as no one is forced to upgrade their pom, you can simply use the old version in the meanwhile...

I have a transitive dependency on this library and the version I used for the main library is fixed. However, the dependency specifies a range of allowed version and the latest will be used. So I was forced to add a gradle dependency constraint

    constraints {
        implementation('org.eclipse.platform:org.eclipse.equinox.preferences:3.9.0') {
            force true
            because "Transitive dependency of org.eclipse.jdt:org.eclipse.jdt.core:3.17.0 newer version of org.eclipse.equinox.preferences points to wrong org.osgi location"
        }
    }

[JohnLBergqvist]

Can you actually remove things from Maven Central? I thought this is a not allowed.

https://stackoverflow.com/questions/9789611/removing-an-artifact-from-maven-central

You can only contact the support, but as no one is forced to upgrade their pom, you can simply use the old version in the meanwhile...

I also have a transitive dependency which is bringing this version in.

[laeubi]

I have a transitive dependency on this library and the version I used for the main library is fixed. However, the dependency specifies a range of allowed version and the latest will be used. So I was forced to add a gradle dependency constraint

Well that's what these features are for... you probably then should better blame the dependency specifying a version range without actually testing that the range is satiable...

[kailbin]

We have the same issue today, the whole CI pipeline is broken because the group Id isn't existed. The current workaround is creating the folder structure as same as the wrong group Id and throwing the jar to there.

So Do We ！！

[cdietrich]

@laeubi all of eclipse platform and also emf have "ranges of death"
e.g. from org.eclipse.core.runtime
https://search.maven.org/artifact/org.eclipse.platform/org.eclipse.core.runtime/3.25.0/jar

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

this leads to always new transitive stuff beeing pulled

[tombrus]

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]

The fixed version was already released yesterday @tombrus

[bjhargrave]

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]

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]

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]

Java SE 11 = class file version 55 . o.e.core.runtime bundle requires it since September 2021 release eclipse-platform/eclipse.platform.runtime@74823fe

[adebiasi]

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

[cdietrich]

@adebiasi can you provide a minimal reproducer

[akurtakov]

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]

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 #61.

[laeubi]

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]

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.