Checking dependency constraints not working
See original GitHub issueAlthough there is an option to enable checking the dependency constrains for updates, it doesn’t work.
Example:
plugins {
id 'java'
id 'com.github.ben-manes.versions' version "0.39.0"
}
group = 'com.example'
sourceCompatibility = '11'
repositories { mavenCentral() }
dependencyUpdates.checkConstraints = true
dependencies {
implementation("ch.qos.logback:logback-classic:1.2.3")
constraints {
constraints {
implementation('org.slf4j:slf4j-api') { version { strictly '1.7.24' } }
}
}
}
Running the dependencyUpdates task results in the following output:
The following dependencies are using the latest milestone version:
- com.github.ben-manes.versions:com.github.ben-manes.versions.gradle.plugin:0.39.0
- org.slf4j:slf4j-api:1.7.24
The following dependencies have later milestone versions:
- ch.qos.logback:logback-classic [1.2.3 -> 1.3.0-alpha5]
http://logback.qos.ch
Checking on maven central shows, that the newest version of slf4j-api is in fact currently 2.0.0-alpha1.
Looking at the Resolver.groovy, around Line 154:
copy.dependencies.clear()
copy.dependencies.addAll(latest)
copy.dependencies.addAll(inherited)
This part cleans up the dependencies from the copied configuration prior running the resolver and doing the actual version checks.
Clearing the dependencyConstraints at that point makes it work like expected for me:
copy.dependencies.clear()
copy.dependencies.addAll(latest)
copy.dependencies.addAll(inherited)
copy.dependencyConstraints.clear()
I think the issue here might be the strictly
constraint, as it effectively disables any further resolution. As we need it to be strictly in our project to downgrade some transitive dependencies, we may not change it to another value, like require
or prefer
.
Could you please consider removing all constraints prior resolving the dependencies?
Thanks, Simon
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (3 by maintainers)
For the time being the below works without plugin changes. It is not pretty, but neither is the resolutionStrategy fix.
For the plugin to make this all less hairy, I think a callback with the
Configuration
would be the most powerful. That means DependencyUpdates.groovy would allow one to set anAction<? super Configuration>
and we’d dispatch to that inResolver
on ourcopy
before resolving. Then a user could do any fix ups they think make sense, like clearing thedependencyConstraints
. This was done forresolutionStrategy
so you could use that as an example to follow.Sure, an option or callback to configure the behavior would be fine too. As this is beyond my groovy / gradle capabilities I cannot help with a PR in that case.