missing guava dependencies when updating from 32.0.1-jre to 32.1.1-jre #6657
Description
My Java project has a transitive dependency on com.google.guava:guava.
I manually update the version of guava by adding a constraint to the dependencies section of my build.gradle:
dependencies {
.....
constraints {
// update guava to latest
implementation("com.google.guava:guava:32.0.1-jre") {
because("cdk uses an old version")
}
}
}
When updating from version 32.0.1-jre to version 32.1.1-jre the following transitive dependencies of guava cannot be resolved:
> Could not find com.google.code.findbugs:jsr305:.
Required by:
project : > com.google.guava:guava:32.1.1-jre
> Could not find org.checkerframework:checker-qual:.
Required by:
project : > com.google.guava:guava:32.1.1-jre
> Could not find com.google.errorprone:error_prone_annotations:.
Required by:
project : > com.google.guava:guava:32.1.1-jre
> Could not find com.google.j2objc:j2objc-annotations:.
Required by:
project : > com.google.guava:guava:32.1.1-jre
I use the official maven repository to resolve dependencies:
repositories {
mavenCentral(name: 'official maven')
}
As there is no such issue of resolving these transitive dependencies when switching back to guava version 32.0.1-jre even after manually deleting all directories that start with com.google in the gradle cache the issue isn't caused by the libraries not being available from the repository.
I cannot (or don't know how to) redact information from the gradle build scan, so I opted for providing you with the console output of gradlew -info clean compileJava.
Please let me know if there is anything else you need to look into this.
Metadata
Metadata
Assignees
Type
Projects
Relationships
Participants
Activity
uli-f commentedon Jul 28, 2023
Output of gradlew -info clean compileJava:
nniesen commentedon Jul 29, 2023
Having the same issue with 32.1.1-jre dependency. I think your new Gradle Module file is broken. Possibly your project has dynamic dependency versions that are not being resolved to fixed versions before creating the Module file.
Dependency
Errors
Work around in our builds :/
cpovirk commentedon Jul 31, 2023
Hmm, thanks for reporting.
Could this have something to do with dependency exclusions, as in the armeria case?
https://github.com/line/armeria/blob/d9076b58f9b2b0e7408246208d1ba62eb3d04428/dependencies.toml#L475-L481
Could it be that those exclusions "work" enough to make Gradle not make the dependency available but don't "work" enough to make it stop looking for them? @jjohannes, I feel I'm repeatedly taking advantage of you here, but I don't know enough to know where to go from here on my own :(
cpovirk commentedon Jul 31, 2023
I accidentally discovered something: My #6659 (to avoid using
dependencyManagement) leads to a similar error:That is probably not surprising to @jjohannes, who had talked about putting version numbers into the Gradle metadata—and, I now see more clearly, doing so as a substitute for
dependencyManagement. I'll leave a comment about this on #6654, too.Declare versions of test-only dependencies inline instead of in our p…
Declare versions of test-only dependencies inline instead of in our p…
jjohannes commentedon Aug 2, 2023
I can't clearly see it from the error messages, but my assumption is that the builds that have this issue somehow (unintentionally) exclude the dependency to
guava-parentthat should bring in the versions. This is new with the Gradle Metadata.See my explanation of why here: #6654 (comment)
@cpovirk I'll have a look if we can inline the versions in the Gradle Metadata as an alternative to 71a16d5. Seeing this issue makes me think it would be better to not have unnecessary divergent between how things are seen by Maven and Gradle.
Put the versions of dependencies directly in Gradle Metadata.
14 remaining items