I’ve also tried all of the intermediate transitive dependencies down from paseto and can’t get it to work. I also tried resolutionStrategy:
configurations.all {
resolutionStrategy {
force 'com.google:guava:33.4.8-jre'
}
}
I tried using guava:33.4.8 (without -jre) thinking that perhaps there is some semantic version subtlety, but it still shows the dependency as guava:31.0.1-jre
I’ve searched extensively, and I see lots of things that say it’s something that can be done, but none of the rituals or incantations seem to work. The built output file contains both guava 31.0.1 and 33.4.8-jre. The issue with that is the corporate scanner sees the 31.0.1 jar and flags it.
If someone could tell me how to make this work, or at least force gradle to print out why it’s not working that would be really appreciated.
A little comment first: You should stop using legacy script plugins (the things you use with “apply from”), they have quite some quirks and are highly discouraged. Especially for declaring versions and coordinates, there is the built-in version catalogs which - especially when used in the TOML form - have many advantages, besides being the built-in idiomatic approach.
Regarding your issue, you should really not use a resolutionStrategy, that is very heavy and low-level hammer that also has its quirks, especially when you try to reason about where some versions are coming from. The constraint is indeed the right way to upgrade (or with strict version also downgrade) a transitive dependency.
Why it does not work in your case is hard to tell from just the snippets you shared. Can you show a build --scan URL? That provides quite extensive information where libraries and their versions are coming from. Or maybe an MCVE?
Especially that both Guava versions make it into the end result sounds also very strange and also demands that you share an MCVE that demonstrates this. This can usually only happen if you take configuration A and configuration B and put files of both to the result, instead of having one configuration that you consume where then version conflict resolution can happen and only one will be taken.
Also, do you by chance apply the Spring Dependency Management Plugin? That is also always a source of confusing and strange and unreasonable behavior when it comes to dependencies and versions. That is a relict from times when Gradle did not have built-in BOM support, by now does more harm than good, and even its maintainer recommends not to use it anymore, but instead the built-in BOM support using platform(...).
And one persona recommendation, you should strongly consider switching to Kotlin DSL. By now it is the default DSL, you immediately get type-safe build scripts, actually helpful error messages if you mess up the syntax, and amazingly better IDE support if you use a good IDE like IntelliJ IDEA or Android Studio.
Now, if only gradle could have pointed that out. Uh, duh, you have a constraint that doesn’t match any dependency.
Well, that’s hardly possible, because that is exactly one of the main use-cases of dependency constraints.
To define a version that is taking part in dependency resolution iff the dependency is in the dependency tree anyway and otherwise not.
A platform / BOM for example is not doing anything else than providing version constraints, for the case you use any of the libs contained.
It’s my major complaint against gradle. When it doesn’t work, there’s no useful information you’re left scratching your head over stupid stuff.
Really?
That was always my experience when being forced to touch Maven.
With Gradle I feel the exact opposite, in most situations it gives perfectly helpful information.
There are indeed situations where it gives bad advice or the error messages still need improvement,
but overall I personally am quite happy with the feedback I get from a Gradle build.
I tried really hard to solve my own problem. I couldn’t because I overlooked a typographical error (vendor had the same word as the end of the group id, and as the artifact id), and no useful diagnostic output was generated, even when I turned on --debug. If the constraint had been scoped to a specific configuration, then I could see your point. But, the constraint wasn’t scoped, and it should have been printed as an error or warning.
But, if it works for you I guess that’s what counts.
If the constraint had been scoped to a specific configuration, then I could see your point. But, the constraint wasn’t scoped, and it should have been printed as an error or warning.
I’m not sure what you mean.
It is scoped to the implementation configuration where you declared it.
Again, yes, for this case there is no help by Gradle.
Gradle cannot know whether there is a dependency at those coordinates that might be valid or not.
It could maybe check whether it is used at all and error out or print a warning.
But that is simply not the use-case for dependency constraints.
Their use-case is to influence the version of a coordinate if it takes part in the resolution and otherwise be ignored.
Similarly, if you for example wanted to use the latest Groovy version and thus use the ccordinates org.codehaus.groovy:groovy:+, you also would not get any indication why Groovy 3 is used and not Groovy 4. (It is because it should have been org.apache.groovy:groovy:+).
The indication that something is not right is actually the absence of the contraint everyhwere.
If you look at a build scan, or at the dependencies task output, or the dependencyInsight task ouput, then a constraint that was used will be displayed. And if it is not displayed, then you most probably mistyped the coordinates.
But, if it works for you I guess that’s what counts.
Not at all, I’m just a user like you and like you sharing your opinion and experience with us, I shared mine with you.
You are free to open a feature request to get the logic changed and then see what the Gradle folks think about it.
