Repository navigation
Gradle unable to resolve Guava in a project, with a VariantSelectionByAttributesException error #8398
Description
Guava Version
33.5.0
Description
In a gradle project I have a build that uses some Java tooling as part of its
build machinery, but is not, itself, a Java project. One of the tooling
dependencies (javaparser) has a dependency on Guava.
For historical reasons that project's build.gradle.kts applied the
java-library plugin. When I removed it because its default tasks were causing
problems with other tasks and, as noted, no Java artifacts were being produced,
the build failed with an error:
Variant Selection Exception:
org.gradle.internal.component.resolution.failure.exception.VariantSelectionByAttributesException
caused by Resolution Failure:
org.gradle.internal.component.resolution.failure.type.NoCompatibleVariantsFailure
Gradle can no longer resolve a Guava variant that it can use. Note that javaparser is explicitly depending on the -jre Guava version. (https://github.com/javaparser/javaparser/blob/11a99ae61df28b19fb9b64e5f7c216fa71dc4020/pom.xml#L432-L437)
There's a minimal repro here: https://github.com/Saxonica/guava-variant-problem
This project contains two Gradle sub-projects, java_lib and
non_java whose build.gradle.kts differ only in the plugin they apply.
non_java applies the base plugin, and java_lib applies the java-library
plugin. They both contain a simple configuration which declares a dependency on
Guava.
Running ./gradlew java_lib:dependencies shows that Guava resolves fine, and
./gradlew non_java:depdendencies shows the failure.
This is defintely unexpected behvaiour, and seems like buggy behaviour, though I
am really not sure if this is a Gradle problem or a Guava Gradle metadata
problem.
I imagine this is related to #7059, #6801 and friends
Example
Clone https://github.com/Saxonica/guava-variant-problem and run the following:
./gradlew non_java:dependencies`Expected Behavior
A properly resolved dependency tree, whose macguffin configuration's dependency tree should be identical to the result of running ./gradlew java_lib:dependencies:
> Task :non_java:dependencies
------------------------------------------------------------
Project ':non_java'
------------------------------------------------------------
macguffin
\--- com.google.guava:guava:33.6.0-jre
+--- com.google.guava:failureaccess:1.0.3
+--- com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava
+--- org.jspecify:jspecify:1.0.0
+--- com.google.errorprone:error_prone_annotations:2.47.0
\--- com.google.j2objc:j2objc-annotations:3.1
macguffinRuntime (n)
\--- com.google.guava:guava:33.6.0-jre (n)
(n) - A dependency or dependency configuration that cannot be resolved.
A web-based, searchable dependency report is available by adding the --scan option.
BUILD SUCCESSFUL in 414ms
Actual Behavior
> Task :non_java:dependencies
------------------------------------------------------------
Project ':non_java'
------------------------------------------------------------
macguffin
\--- com.google.guava:guava:33.6.0-jre FAILED
macguffinRuntime (n)
\--- com.google.guava:guava:33.6.0-jre (n)
(n) - A dependency or dependency configuration that cannot be resolved.
A web-based, searchable dependency report is available by adding the --scan option.
BUILD SUCCESSFUL in 414ms
Packages
No response
Platforms
No response
Checklist
-
I agree to follow the code of conduct.
-
I can reproduce the bug with the latest version of Guava available.
Activity
dokson commentedon May 3, 2026
Hi @fidothe — the linked repro at
https://github.com/Saxonica/guava-variant-problemreturns 404. Could you confirm whether the repo was moved, renamed, or made private? An updated link (or a gist with the twobuild.gradle.ktsfiles) would help anyone trying to investigate. Thanks!fidothe commentedon May 3, 2026
Apologies, that repo has been made public now.
dokson commentedon May 3, 2026
Not a maintainer, just chiming in with a verified workaround.
I cloned the reproducer and confirmed both the failure and a one-line fix on the consumer side.
Why it fails. Guava's Gradle Module Metadata declares the standard
org.gradle.jvm.environmentattribute (standard-jvm/android) on every variant — that's what lets Gradle disambiguate-jrefrom-androidautomatically (the reason Guava adopted GMM, cf. #6801). The JVM plugins (java,java-base,java-library) register anAttributesSchemawith compatibility/disambiguation rules for that attribute and its companions (usage,libraryelements,category,bundling). Thebaseplugin does not, so Gradle has no rules to match the producer's variants against an empty consumer-side attribute set, henceNoCompatibleVariantsFailure.Workaround (one line). Gradle ships a plugin meant exactly for this case — consuming JVM libraries from a non-JVM project. In
non_java/build.gradle.kts:plugins { base `jvm-ecosystem` }jvm-ecosystemregisters the JVM attributes schema without producing any Java artifacts or tasks. With it applied, on your reproducer:i.e. identical to the
java_liboutput. Verified locally with Gradle 9.5 and Guava 33.6.0-jre.Reference: https://docs.gradle.org/current/userguide/jvm_ecosystem_plugin.html
Whether this is something Guava should document for non-JVM consumers, or whether the metadata should be adjusted, is up to the maintainers — but at least there's a working fix in the meantime.
fidothe commentedon May 5, 2026
@dokson Thanks for that. I also later found that advice from the Gradle forums.
I guess my question for the Guava maintainers is whether this needs to be mitigated with documentation, or if there are changes to the Gradle metadata which would make it work.
I would have assumed that explicitly depending on the
-jreversion, asjavaparserdoes, would help with disambiguating, but it's really unclear from the Gradle documentation.In any case, it seems like providing Gradle module metadata is enough to make Gradle be much more restrictive in how it decides on which artifact versions are acceptable. Our use case, where we're using
javaparserto produce information we need to transpile Java code to C#, may be a little unusual, but the general pattern of using java dependencies in build tooling for building non-java things doesn't seem that unusual at all.giruuuuj commentedon May 22, 2026
This issue has been resolved by PR #8442.
Root cause: Guava publishes Gradle Module Metadata declaring
org.gradle.jvm.environmenton all variants. Projects without thejvm-ecosystemorjava-libraryplugin cannot resolve Guava because they lack the attribute schema needed to match these variants.Fix: Added two new fallback variants (
apiElements,runtimeElements) tomodule.jsonthat omit theorg.gradle.jvm.environmentattribute. When a consumer does not declare JVM environment attributes, Gradle falls back to these variants.Workaround for older versions: Apply the
jvm-ecosystemplugin in your build script:plugins { base `jvm-ecosystem` }See #8442 for the full implementation.
pangwangshu commentedon Aug 4, 2026
Is it still open? My PR added corrected the document.