Closed niktekusho closed 3 years ago
My guess is that something like the following is happening:
org.eclipse.platform:dep-you-asked-for
depends on transitive-dep-you-didnt-ask-for:[1.2.3,2.0.0)
[1.2.3,2.0.0)
resolves to something new, which might itself have new transitivesIn terms of fixing this, some solutions are:
eclipseMavenCentral
to constrain the versions of transitive resolutions (doable but tricky)I'd be happy to take a PR for option 3, but it won't make the top of my todo list. I would implement it as constrainTransitiveVersionsToThisRelease()
, similar to
Understood. Thanks for the heads up: I ended up forcing dependencies' versions in the Gradle dependency resolution.
Sample code for future readers
allprojects {
configurations {
all {
// Lock dependency to specific version
resolutionStrategy.force 'org.eclipse.platform:org.eclipse.ui.workbench:3.113.0'
}
}
}
I bumped into this same issue, and resolved it with the commit above, just FYI.
Thank you very much. 👍
Hi, recently, we started having problems resolving a transitive dependency of an eclipse plugin.
Disclaimer: this might be a problem on the eclipse side of things.
Even though we set a specific release version of eclipse (4.11.0), the jars goomph downloads seem to be released much later.
I discovered this because, in the recent days, our internal build pipeline started to behave strangely: in a sudden
org.eclipse.platform:org.eclipse.e4.core.di
dependency tried to pull a "strange" version ofjavax-annotations-api
, which cannot be found even on maven central:I put together a small reproduction project, and you can find it attached to this issue. goomph-dep.zip
Here is a Gradle build scan of the failure: https://scans.gradle.com/s/zawvnmvueqvze
To reproduce locally:
./gradlew dependencyInsight --dependency 'org.eclipse.ui.workbench'