missing guava dependencies when updating from 32.0.1-jre to 32.1.1-jre #6657
Labels
Milestone
Comments
|
Output of gradlew -info clean compileJava: |
|
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 :/ |
|
Hmm, thanks for reporting. Could this have something to do with dependency exclusions, as in the armeria case? 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 :( |
|
I accidentally discovered something: My #6659 (to avoid using 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 |
copybara-service bot
pushed a commit
that referenced
this issue
Jul 31, 2023
…arent pom. Fixes #6654, I hope? If `guava` and its parent pom don't refer to `mockito-core`, then `guava` should no longer affect which version of `mockito-core` is selected by Gradle. (Really, it "shouldn't" even now, but there's a mismatch between Maven's model and Gradle's that causes it to do so.) I had initially attempted (in cl/552479838) to declare versions of _all_ our dependencies inline, but that [didn't work](#6657 (comment)): We [really need `dependencyManagement` for Gradle purposes, at least until we specify versions for Gradle explicitly](#6654 (comment)). It would be nice if we could still declare our dependency versions only once, now by using `properties`. (In fact, my attempt to use `properties` made me notice that our version of the Error Prone _plugin_ is older than our version of the Error Prone _annotations_.) However, if we were to make that change, then we'd lose the ability to update dependencies with `versions-maven-plugin` (`update-properties` + `use-latest-releases`), I assume because the properties are declared in one `pom.xml` and used in another. (It's possible that Dependabot is better about this, but we've had trouble getting it to work with our unusual 2-flavor, Google-repo-source-of-truth setup.) I notice that we have this problem even today with `truth.version`.... Tested: ``` $ mvn dependency:tree -Dverbose -X -U &> /tmp/pre # made changes $ mvn dependency:tree -Dverbose -X -U &> /tmp/post $ strip() { cat "$@" | grep -v -e 'Dependency collection stats' -e 'Downloading from' -e 'Progress' -e 'Using connector' -e 'Using transporter' -e 'Using mirror' -e maven-dependency-plugin -e SUCCESS -e 'Total time' -e 'Finished at' | sed -e 's/ (.*managed from.*)//'; }; vimdiff <(strip /tmp/pre) <(strip /tmp/post) ``` RELNOTES=Changed our Maven project to avoid [affecting which version of Mockito our Gradle users see](#6654). PiperOrigin-RevId: 552508216
copybara-service bot
pushed a commit
that referenced
this issue
Jul 31, 2023
…arent pom. Fixes #6654, I hope? If `guava` and its parent pom don't refer to `mockito-core`, then `guava` should no longer affect which version of `mockito-core` is selected by Gradle. (Really, it "shouldn't" even now, but there's a mismatch between Maven's model and Gradle's that causes it to do so.) I had initially attempted (in cl/552479838) to declare versions of _all_ our dependencies inline, but that [didn't work](#6657 (comment)): We [really need `dependencyManagement` for Gradle purposes, at least until we specify versions for Gradle explicitly](#6654 (comment)). It would be nice if we could still declare our dependency versions only once, now by using `properties`. (In fact, my attempt to use `properties` made me notice that our version of the Error Prone _plugin_ is older than our version of the Error Prone _annotations_.) However, if we were to make that change, then we'd lose the ability to update dependencies with `versions-maven-plugin` (`update-properties` + `use-latest-releases`), I assume because the properties are declared in one `pom.xml` and used in another. (It's possible that Dependabot is better about this, but we've had trouble getting it to work with our unusual 2-flavor, Google-repo-source-of-truth setup.) I notice that we have this problem even today with `truth.version`.... Tested: ``` $ mvn dependency:tree -Dverbose -X -U &> /tmp/pre # made changes $ mvn dependency:tree -Dverbose -X -U &> /tmp/post $ strip() { cat "$@" | grep -v -e 'Dependency collection stats' -e 'Downloading from' -e 'Progress' -e 'Using connector' -e 'Using transporter' -e 'Using mirror' -e maven-dependency-plugin -e SUCCESS -e 'Total time' -e 'Finished at' | sed -e 's/ (.*managed from.*)//'; }; vimdiff <(strip /tmp/pre) <(strip /tmp/post) ``` RELNOTES=Changed our Maven project to avoid [affecting which version of Mockito our Gradle users see](#6654). PiperOrigin-RevId: 552549819
|
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 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. |
copybara-service bot
pushed a commit
that referenced
this issue
Aug 2, 2023
This makes the version handling in POM and Gradle Metadata more similar. See #6654 (comment) We expect this to fix #6657, though we don't fully understand it. Fixes #6664 RELNOTES=Changed Gradle Metadata to include dependency versions directly. This may address ["Could not find `some-dependency`" errors](#6657) that some users have reported (which might be a result of users' excluding `guava-parent`). PiperOrigin-RevId: 553180806
|
@jjohannes I don't know if this will help or is relevant to your build process but... We have an internal gradle bom project and to get it to inherit included boms, so our consumers only need to specify our bom, we had to add the following to our Gradle file. We also followed this post to ensure dynamic dependency versions were resolve/pinned in the publish pom: I do see you have a resolution that works for you so not looking for a change. |
jrhee17
added a commit
to line/armeria
that referenced
this issue
Aug 8, 2023
Note that some dependencies have some issues which need resolving before upgrading: - Guava: google/guava#6657 **Dependencies ** - gRPC-Java 1.56.1 -> 1.57.1 - GraphQL Kotlin 6.5.2 -> 6.5.3 - Jakarta Websocket 2.1.0 -> 2.1.1 - Kafka client 3.4.0 -> 3.4.1 - Kotlin 1.8.22 -> 1.9.0 - Kotlin Coroutine 1.7.1 -> 1.7.3 - Micrometer 1.11.1 -> 1.11.2 - Netty 4.1.95.Final -> 4.1.96.Final - Protobuf 3.22.3 -> 3.23.4 - Reactor 3.5.7 -> 3.5.8 - Resilience4j 2.0.2 -> 2.1.0 - Resteasy 5.0.5.Final -> 5.0.7.Final - Sangria 4.0.0 -> 4.0.1 - scala-collection-compat 2.10.0 -> 2.11.0 - Spring 6.0.9 -> 6.0.11 - Spring Boot 2.7.12 -> 2.7.14, 3.1.0 -> 3.1.1 - Tomcat 10.1.10 -> 10.1.11 - Build - Dagger 2.46.1 -> 2.47 - dgs 5.5.0 -> 7.3.6 - Error Prone 2.19.1 -> 2.20.0 - Eureka 2.0.0 -> 2.0.1 - gax-grpc 2.29.0 -> 2.31.1 - Gradle 8.1.1 -> 8.2.1 - Groovy 3.0.17 -> 3.0.18 - Hibernate Validator 8.0.0.Final -> 8.0.1.Final - Java Websocket 1.5.3 -> 1.5.4 - JUnit 5.9.3 -> 5.10.0 - Kafka 3.4.1 -> 3.5.1 - ktlint-gradle-plugin 11.3.2 -> 11.4.0 - Snappy 1.1.9.1 -> 1.1.10.3 - TestNG 7.5 -> 7.5.1 --------- Co-authored-by: Trustin Lee <[email protected]>
copybara-service bot
pushed a commit
to androidx/media
that referenced
this issue
Nov 1, 2023
This is slightly out of sync with the version in AOSP (32.1.2) but the diff is minimal, and we need 32.1.3 here as it contains the fix for google/guava#6657. PiperOrigin-RevId: 578572893
copybara-service bot
pushed a commit
to google/ExoPlayer
that referenced
this issue
Nov 1, 2023
This is slightly out of sync with the version in AOSP (32.1.2) but the diff is minimal, and we need 32.1.3 here as it contains the fix for google/guava#6657. PiperOrigin-RevId: 578572893
This was referenced Dec 2, 2023
copybara-service bot
pushed a commit
to google/google-java-format
that referenced
this issue
Dec 7, 2023
There is an issue about resolving transitive dependencies in Guava breaks GJF 1.18.1 integration in [Spotless](https://github.com/diffplug/spotless), which has been fixed in Guava 32.1.3, it would be nice to follow this update. See: - google/guava#6657. - https://github.com/google/guava/releases/tag/v32.1.3. Fixes #996 FUTURE_COPYBARA_INTEGRATE_REVIEW=#996 from Goooler:bump-guava 1e5ed85 PiperOrigin-RevId: 588821550
copybara-service bot
pushed a commit
to google/google-java-format
that referenced
this issue
Dec 7, 2023
There is an issue about resolving transitive dependencies in Guava breaks GJF 1.18.1 integration in [Spotless](https://github.com/diffplug/spotless), which has been fixed in Guava 32.1.3, it would be nice to follow this update. See: - google/guava#6657. - https://github.com/google/guava/releases/tag/v32.1.3. Fixes #996 COPYBARA_INTEGRATE_REVIEW=#996 from Goooler:bump-guava 1e5ed85 PiperOrigin-RevId: 588824173
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
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:When updating from version
32.0.1-jreto version32.1.1-jrethe following transitive dependencies of guava cannot be resolved:I use the official maven repository to resolve dependencies:
As there is no such issue of resolving these transitive dependencies when switching back to guava version
32.0.1-jreeven after manually deleting all directories that start withcom.googlein 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.
The text was updated successfully, but these errors were encountered: