Gradle Metadata of 32.1.0 has a SNAPSHOT version number

[jjohannes]

I am very sorry @cpovirk but the Gradle Metadata just published is broken. If you look at these two files:

• https://repo1.maven.org/maven2/com/google/guava/guava/32.1.0-jre/guava-32.1.0-jre.module
• https://repo1.maven.org/maven2/com/google/guava/guava/32.1.0-android/guava-32.1.0-android.module

You see several versions like HEAD-android-SNAPSHOT in them.

I believe this is because the util/set_version.sh script was not used to set the version here.
My assumption was that this is somehow automatically used before each release. So I did not think about that further. I guess I was wrong and that's not the case. 😞

These lines need to be executed on a version change:
https://github.com/google/guava/blob/master/util/set_version.sh#L18-L21

I am afraid this requires patching, as in certain situations the metadata now points at files not available on Maven Central.

[cpovirk]

Ouch, thank you for catching that.

I suspect that what happened is that, when we reworked our release process a couple years back, we copied the set_version logic into the new scripts and then never deleted the old script. I, too, had assumed that it would be run, but I had enough information that I could have thought to question that.

I'll update the release notes, delete the old script, update the new script, and publish a new release.

[cpovirk]

OK, 32.1.1 is published, and I ran a couple tests beforehand that suggest this problem should be fixed:

• grep SNAPSHOT ~/.m2/repository/com/google/guava/guava/32.1.1-*/guava-32.1.1-*.module # no results; has results for 32.1.0
• util/gradle_integration_tests.sh # passes; failed at v32.1.0

[jjohannes]

Thanks for following up so quick! The 32.1.1 module files look correct to me.

[bjwyse]

I am seeing an issue with a Spring Boot project when doing Gradle Reload. The issue is related to the Guava module, and it seems to be trying to use that new version 32.1.1?

Any advice please as I think it might be related to this recent issue?

`

Could not resolve all artifacts for configuration ':classpath'.
Could not resolve com.google.guava:guava:30.1-jre.
Required by:
project : > com.google.cloud.tools.jib:com.google.cloud.tools.jib.gradle.plugin:2.8.0 > gradle.plugin.com.google.cloud.tools:jib-gradle-plugin:2.8.0
> The consumer was configured to find a runtime of a library compatible with Java 15, packaged as a jar, and its dependencies declared externally. However we cannot choose between the following variants of com.google.guava:guava:32.1.1-jre:
- androidRuntimeElements
- jreRuntimeElements
All of them match the consumer attributes:
- Variant 'androidRuntimeElements' capabilities com.google.collections:google-collections:32.1.1-jre and com.google.guava:guava:32.1.1-jre and com.google.guava:listenablefuture:1.0 declares a runtime of a library compatible with Java 8, packaged as a jar, and its dependencies declared externally:

`

[cpovirk]

Thanks. I'll leave another warning in the release notes :(

I wonder if the Selecting the appropriate flavor code snippet would be of help here, except with "STANDARD_JVM" instead of "ANDROID"? But @jjohannes is more likely to be of help.

[jjohannes]

@bjwyse are you running Gradle 6.x? You need to add something like this to a place where you configure the Java plugins:

sourceSets.all {
  configurations.getByName(runtimeClasspathConfigurationName) {
    attributes.attribute(Attribute.of("org.gradle.jvm.environment", String), "standard-jvm")
  }
  configurations.getByName(compileClasspathConfigurationName) {
    attributes.attribute(Attribute.of("org.gradle.jvm.environment", String), "standard-jvm")
  }
}

Starting with Gradle 7.0, Gradle automatically supports the org.gradle.jvm.environment attribute.

@cpovirk maybe that's something to add to the release notes. I also didn't hink of that before. It only concerns 6.x users. Older versions won't pick up the metadata and starting with 7.x it is automatically supported.

[cpovirk]

Thanks, @jjohannes. I've updated the release notes to mention this.

[tanmaymanolkar1]

Hi @cpovirk,
Iver read the release notes for https://github.com/google/guava/releases/tag/v32.1.0.

Our library depends on MapDB 3.0.8 which has a dependency on guava library:

This is the error I am seeing now, is there any way I could resolve it, since we are having a secondary dependency on guava.

Thank you for your help in advance!

[ashwinibairyruge]

Hi, I am facing issue
A problem occurred configuring root project 'platform'.

Could not resolve all artifacts for configuration ':classpath'.
Could not resolve com.google.guava:guava:[14,).
Required by:
project : > com.smokejumperit.gradle.license:Gradle-License-Report:0.0.2
> The consumer was configured to find a runtime of a library compatible with Java 8, packaged as a jar, and its dependencies declared externally. However we cannot choose between the following variants of com.google.guava:guava:32.1.1-jre:
- androidRuntimeElements
- jreRuntimeElements

[jjohannes]

Hi @ashwinibairyruge - a fundamental flaw in this setup is that the com.smokejumperit.gradle.license:Gradle-License-Report plugin is declaring a dependency with com.google.guava:guava:[14,) (open version range). This means the build will regularly check for new Guava versions and may suddenly break. The plugin should declare a fixed version. The plugin looks unmaintained. Maybe you should replace it if you can. Or, independent of this issue, I would recommend to pin the dynamic versions yourself by adding constraints:

buildscript {
    dependencies.constraints {
        classpath("com.google.guava:guava:<some-fixed-guava-version>")
    }
}

---

To get it working with the new Guava version, the best solution is to upgrade to Gradle 7.x or Gradle 8.x.

If that is not possible, for Gradle 6.x you need to set the above mentioned attribute for Gradle's own classpath:

buildscript {
    configurations.classpath {
        attributes.attribute(Attribute.of("org.gradle.jvm.environment", String), "standard-jvm")
    }
}

[jjohannes]

@tanmaymanolkar1 your issue is similar. MapDB should not publish dynamic version dependencies. For example, they should use 15.0 instead of [15.0,) for Guava (maybe you want to open an issue there?).

To fix the problem with the new Guava version, update to Gradle 7.x or Gradle 8.x.

Or follow the advice here for 6.x: #6612 (comment)

[rochish-suresh]

I am using 7.x version of gradle but receiving the #6612 (comment)

Gradle version: 7.6.1

[2023-07-06T11:05:57.418Z] * What went wrong:
[2023-07-06T11:05:57.418Z] Execution failed for task
[2023-07-06T11:05:57.418Z] > Could not resolve all files for configuration
[2023-07-06T11:05:57.418Z] > Could not resolve com.google.guava:guava:32.1.1-jre.
[2023-07-06T11:05:57.418Z] Required by:
[2023-07-06T11:05:57.418Z] project :deployment > project
The consumer was configured to find attribute 'org.gradle.dependency.bundling' with value 'external'. However we cannot choose between the following variants of com.google.guava:guava:32.1.1-jre:
[2023-07-06T11:05:57.419Z] - androidRuntimeElements
[2023-07-06T11:05:57.419Z] - jreRuntimeElements
[2023-07-06T11:05:57.419Z] All of them match the consumer attributes:
[2023-07-06T11:05:57.419Z] - Variant 'androidRuntimeElements' capabilities com.google.collections:google-collections:32.1.1-jre and com.google.guava:guava:32.1.1-jre and com.google.guava:listenablefuture:1.0 declares attribute 'org.gradle.dependency.bundling' with value 'external':
[2023-07-06T11:05:57.419Z] - Unmatched attributes:
[2023-07-06T11:05:57.419Z] - Provides org.gradle.category 'library' but the consumer didn't ask for it

@jjohannes

[jjohannes]

@rochish-suresh that is unexpected. The error trace you posted looks incomplete, but from "Provides org.gradle.category 'library' but the consumer didn't ask for it" I assume this is some custom dependency resolution. Meaning, it is not about the normal compileClasspath or runtimeClasspath.

When the org.gradle.jvm.environment attribute was introduced in 7.0, it was done in a way that should make it default to standard-jvm in such custom dependency resolution scenarios.

Without more context, I can't tell why it is not sufficient in your case.

Are you able to share a reproducer, or a build scan and/or the output of the dependencies task?

[JackRyanTR]

We're seeing the same issue - is there an ETA on a fix?

[johannesup]

We're also facing the same issue @jjohannes ... I can't provide a reproducer, but we included the JRE dependendency (32.1.1-jre) and specified

configurations.all {
  resolutionStrategy.capabilitiesResolution.withCapability("com.google.collections:google-collections") {
    select("com.google.guava:guava:0")
  }
  // and/or
  resolutionStrategy.capabilitiesResolution.withCapability("com.google.guava:listenablefuture") {
    select("com.google.guava:guava:0")
  }
}

  org.gradle.internal.component.AmbiguousConfigurationSelectionException: Cannot choose between the following variants of com.google.guava:guava:32.1.1-jre:
    - androidRuntimeElements
    - jreRuntimeElements
  All of them match the consumer attributes:
    - Variant 'androidRuntimeElements' capabilities com.google.collections:google-collections:32.1.1-jre and com.google.guava:guava:32.1.1-jre and com.google.guava:listenablefuture:1.0:
        - Unmatched attributes:
            - Provides org.gradle.category 'library' but the consumer didn't ask for it
            - Provides org.gradle.dependency.bundling 'external' but the consumer didn't ask for it
            - Provides org.gradle.jvm.environment 'android' but the consumer didn't ask for it
            - Provides org.gradle.jvm.version '8' but the consumer didn't ask for it
            - Provides org.gradle.libraryelements 'jar' but the consumer didn't ask for it
            - Provides org.gradle.status 'release' but the consumer didn't ask for it
            - Provides org.gradle.usage 'java-runtime' but the consumer didn't ask for it
    - Variant 'jreRuntimeElements' capabilities com.google.collections:google-collections:32.1.1-jre and com.google.guava:guava:32.1.1-jre and com.google.guava:listenablefuture:1.0:
        - Unmatched attributes:
            - Provides org.gradle.category 'library' but the consumer didn't ask for it
            - Provides org.gradle.dependency.bundling 'external' but the consumer didn't ask for it
            - Provides org.gradle.jvm.environment 'standard-jvm' but the consumer didn't ask for it
            - Provides org.gradle.jvm.version '8' but the consumer didn't ask for it
            - Provides org.gradle.libraryelements 'jar' but the consumer didn't ask for it
            - Provides org.gradle.status 'release' but the consumer didn't ask for it
            - Provides org.gradle.usage 'java-runtime' but the consumer didn't ask for it

[jjohannes]

@johannesup and others: can you please share the complete error message. The last part is always the same. But the interesting bit is which classpath (aka Configuration) Gradle is attempting to use/resolve.

Also:

• If you are on Gradle 6 update to 7 or 8 or follow the suggestions stated above - Gradle Metadata of 32.1.0 has a SNAPSHOT version number #6612 (comment) - and in the release notes. This is expected to be an issue with Gradle 6 that requires additional configuration on the user side.
• If you have such an issue with Gradle 7 or 8, share the complete error message. Or better a reproducer and/or a Build Scan if you can.

[jjohannes]

Assuming you are on Gradle 6 @johannesup, did you add #6612 (comment)?

[jjohannes]

@deepamalik18 This part of the message...

https://docs.gradle.org/6.7.1/userguide/command_line_interface.html#sec:command_line_warnings

tells you that your run Gradle 6.7.1. Maybe your CI configuration picks a different version than it is supposed to.

[rochish-suresh]

Adding the org.gradle.usage=java-runtime and org.gradle.jvm.environment=standard-jvm into my configuration that worked. Thanks @jjohannes

[somalaya]

Adding the org.gradle.usage=java-runtime and org.gradle.jvm.environment=standard-jvm into my configuration that worked. Thanks @jjohannes

Hi @rochish-suresh,I am also facing the same issue on gradle 7.5.1, could you please specify what you mean by adding the above values to configuration? Did you add them to your gradle.properties file?

[somalaya]

Hi @jjohannes, I am on gradle 7.5.1 and I am still getting this error

Execution failed for task ':LinuxBroker:compileKotlin'.

Could not resolve all files for configuration ':LinuxBroker:compileClasspath'.
Could not resolve com.google.guava:guava:[15.0,).
Required by:
project :LinuxBroker > org.mapdb:mapdb:3.0.8
> The consumer was configured to find an API of a library compatible with Java 8, preferably in the form of class files, and its dependencies declared externally, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm'. However we cannot choose between the following variants of com.google.guava:guava:32.1.2-jre:
- androidApiElements
- jreApiElements
All of them match the consumer attributes:
- Variant 'androidApiElements' capabilities com.google.collections:google-collections:32.1.2-jre and com.google.guava:guava:32.1.2-jre declares an API of a library compatible with Java 8, packaged as a jar, and its dependencies declared externally:
- Unmatched attributes:
- Provides attribute 'org.gradle.jvm.environment' with value 'android' but the consumer didn't ask for it
- Provides release status but the consumer didn't ask for it
- Doesn't say anything about org.jetbrains.kotlin.platform.type (required 'jvm')
- Variant 'jreApiElements' capabilities com.google.collections:google-collections:32.1.2-jre and com.google.guava:guava:32.1.2-jre declares an API of a library compatible with Java 8, packaged as a jar, and its dependencies declared externally:
- Unmatched attributes:
- Provides attribute 'org.gradle.jvm.environment' with value 'standard-jvm' but the consumer didn't ask for it
- Provides release status but the consumer didn't ask for it
- Doesn't say anything about org.jetbrains.kotlin.platform.type (required 'jvm')

Can you please help me with this? I did not make any fixes suggested for 6.x. We are just consuming mapDB and seeing this error.

[jjohannes]

@somalaya I am surprised that you get this with Gradle versions > 6. The compile classpath should have the "standard-jvm" already set. But looks like it does not have that in your case. You can set it like this for example:

configurations.compileClasspath {
    attributes.attribute(TargetJvmEnvironment.TARGET_JVM_ENVIRONMENT_ATTRIBUTE,
            objects.named(TargetJvmEnvironment, TargetJvmEnvironment.STANDARD_JVM))
}

Do that in the build.gradle of LinuxBroker or in the convention plugin (if you have that) where you configure things like the Java/Kotlin compilation.

[retrofun]

Hello,

yesterday at work I had the same issue when running the jiraconnector-gradle-plugin.

I've created and attached a sample gradle 8.2.1 project where the issue occurs.
Extract the tarball, cd into the guava_issue_6612 directory and run jiraconnector task
$ ./gradlew setIssueField

...
> Could not resolve all files for configuration ':jiraRestClient'.
   > Could not resolve com.google.guava:guava:26.0-jre.
     Required by:
         project : > com.atlassian.jira:jira-rest-java-client-api:5.2.1
      > Cannot choose between the following variants of com.google.guava:guava:32.1.2-jre:
          - androidRuntimeElements
          - jreRuntimeElements
        All of them match the consumer attributes:
          - Variant 'androidRuntimeElements' capabilities com.google.collections:google-collections:32.1.2-jre and com.google.guava:guava:32.1.2-jre:
              - Unmatched attributes:
...

You can switch between working and non-working in build.gradle here:

configurations {
    jiraRestClient {
        resolutionStrategy {
//            force 'com.google.guava:guava:32.0.1-jre' // works
            force 'com.google.guava:guava:32.1.2-jre' // >= 32.1.0 won't work
        }
    }
}

Working means the failure with guava does not occur but the jiraconnector-gradle-plugin will then fail of course because of bogus configuration data.

Thanks.

guava_issue_6612.tar.gz

[cpovirk]

Also in "All of them match the consumer attributes," here is a Stack Overflow question that I'm not sure how to help with.

[retrofun]

I digged a bit deeper in my sample project guava_issue_6612:

When the equivalent of attribute org.gradle.jvm.environment = 'standard-jvm' is added to the project with

configurations {
    jiraRestClient {
        attributes {
            attribute(Attribute.of('org.gradle.jvm.environment', String), 'standard-jvm')
        }
        resolutionStrategy {
...

./gradlew setIssueField gives this error:

> Could not resolve all files for configuration ':jiraRestClient'.
   > Could not find org.checkerframework:checker-qual:.
     Required by:
         project : > com.atlassian.jira:jira-rest-java-client-api:5.2.1 > com.google.guava:guava:32.1.2-jre
   > Could not find com.google.errorprone:error_prone_annotations:.
     Required by:
         project : > com.atlassian.jira:jira-rest-java-client-api:5.2.1 > com.google.guava:guava:32.1.2-jre

Finally, when the java plugin is added - and the attribute org.gradle.jvm.environment = 'standard-jvm' is removed - it works with guava >= 32.1.0.

plugins {
    // https://github.com/IntershopCommunicationsAG/jiraconnector-gradle-plugin
    id 'com.intershop.gradle.jiraconnector' version '6.3.0'
    id 'java'
}

Maybe this helps someone...

[jjohannes]

Thanks for sharing this @retrofun. I can give some background then on why it broke. Usually, if you use Java libraries (like Guava) you need a "Java" project so that Gradle has some knowledge about concepts like "compile time" and "runtime". These are not core Gradle dependency management concepts, as Gradle's core dependency management is more generic.

However, historically, Java was and is the main application area of Gradle. And there are quite some fallback mechanisms for backward compatibility that make things work "most of the time" even outside of a Java project. It's a bit unlucky. Maybe it would be better if it would never work outside a Java project. And it definitely could be better documented.

Instead of id 'java' you may use id 'jvm-ecosystem' - this is the basic plugin that only adds the rules for dependency management and no other Java specific things (such as Java source code compilation tasks).

It also looks to me as if jiraRestClient comes out of the com.intershop.gradle.jiraconnector plugin. So maybe that plugin should/can already apply id 'jvm-ecosystem'. (You may consider opening an issue there.)
I had a similar situation in this plugin I maintain: gradlex-org/jvm-dependency-conflict-resolution#46 (comment)

[ZacSweers]

This change to guava has been incredibly annoying to deal with across multiple repos. Some gradle plugins use guava as a transitive dependency in opaque configurations that then require project maintainers to go do silly workarounds like have been articulated in the above comments.

The number of PRs linking back to this with various workarounds I feel is indicative of this being a recurring papercut now. I strongly feel the original goal of making guava dependency management easier has not been met, and actually made worse by this change. Would you be open to rolling back this change for now until a better solution is found?

[danlewis783]

We attempted to upgrade Guava in our Gradle version catalog from 31.1-jre to 32.1.2-jre. We are on Gradle 8.2.1 and Kotlin.
Not sure why this issue was closed we are still having issues.

Could not resolve com.google.guava:guava:32.1.2-jre.
Required by:
project :
> Cannot choose between the following variants of com.google.guava:guava:32.1.2-jre:
- androidRuntimeElements
- jreRuntimeElements
All of them match the consumer attributes:
- Variant 'androidRuntimeElements' capabilities com.google.collections:google-collections:32.1.2-jre and com.google.guava:guava:32.1.2-jre:
- Unmatched attributes:
- Provides org.gradle.category 'library' but the consumer didn't ask for it
- Provides org.gradle.dependency.bundling 'external' but the consumer didn't ask for it
- Provides org.gradle.jvm.environment 'android' but the consumer didn't ask for it
- Provides org.gradle.jvm.version '8' but the consumer didn't ask for it
- Provides org.gradle.libraryelements 'jar' but the consumer didn't ask for it
- Provides org.gradle.status 'release' but the consumer didn't ask for it
- Provides org.gradle.usage 'java-runtime' but the consumer didn't ask for it
- Variant 'jreRuntimeElements' capabilities com.google.collections:google-collections:32.1.2-jre and com.google.guava:guava:32.1.2-jre:
- Unmatched attributes:
- Provides org.gradle.category 'library' but the consumer didn't ask for it
- Provides org.gradle.dependency.bundling 'external' but the consumer didn't ask for it
- Provides org.gradle.jvm.environment 'standard-jvm' but the consumer didn't ask for it
- Provides org.gradle.jvm.version '8' but the consumer didn't ask for it
- Provides org.gradle.libraryelements 'jar' but the consumer didn't ask for it
- Provides org.gradle.status 'release' but the consumer didn't ask for it
- Provides org.gradle.usage 'java-runtime' but the consumer didn't ask for it

[cpovirk]

@danlewis783, are the instructions for the "All of them match the consumer attributes" error in the release notes of any help? If not, you may be able to try the instructions for "Selecting the appropriate flavor." If neither of those helps, let's spin this off to another issue: As you can gather from the @ZacSweers post above yours, there are a number of ways in which projects can break from the Gradle metadata :\ This issue was intended to be about one specific problem with the version numbers in the metadata, a problem that we fixed, but the issue has become a catch-all.

@ZacSweers, I'll try to take stock of things next week.

[danlewis783]

@danlewis783, are the instructions for the "All of them match the consumer attributes" error in the release notes of any help?

Yes they were helpful but they didn't work in my situation. For better context, the error above occurs when we to verify that our version catalog can resolve all the dependencies prior to publishing the catalog for consumption by other Gradle projects. The code looks something like this:

val catalogCheck = tasks.register("catalogCheck") {
    outputs.upToDateWhen { false }
    doLast {
        val catalogExtension: CatalogExtensionInternal = catalog as CatalogExtensionInternal
        val versionCatalog: DefaultVersionCatalog = catalogExtension.versionCatalog.get()
        val projectDependencies: DependencyHandler = dependencies
        val configuration: Configuration = configurations.create("aliasCheck")
        configuration.setTransitive(false)
        val toAdd: MutableList<String> = mutableListOf()
        versionCatalog.libraryAliases.map {
            val dm: DependencyModel = versionCatalog.getDependencyData(it)
            val group: String = dm.group
            val artifact: String = dm.name
            val version: String = dm.version.toString()
            // junit-jupiter-params and guava fails with "Cannot choose between the following variants..."
            if (artifact != "junit-jupiter-params" && artifact != "guava") {
                toAdd.add("$group:$artifact:$version")
            }
        }
//to confirm this all works, uncomment this bogus dependency and run
//        toAdd.add("foo:bar:1.2.3")
        configuration.defaultDependencies {
            toAdd.forEach {
                add(projectDependencies.create(it))
            }
        }
        configuration.resolve()
    }
}

As you can see, we have the same issue with another library in our catalog: junit-jupiter-params. Our environment is Gradle 8.2.1 on Eclipse Adoptium 11.0.19 on Windows 10.

[jjohannes]

@danlewis783 is the project that custom task is defined in a "Java project" so that it knows the selection rules of the "Java world"?

If not make sure to apply th id 'jvm-ecosystem' plugin. See #6612 (comment).

I think that you also have issues with another library shows that this is not a Guava issue. But an issue of communication/documentation of Gradle.

[ZacSweers]

I've gone down the rabbit hole on this and found that it's not actually possible to force JRE guava in android projects, wrote up a longer analysis here if anyone wants to follow: #6801

[renatoathaydes]

I had some trouble to come up with a solution that worked for me due to my configurations having some modifications which made the original solution (of adding the jvm-ecosystem plugin) fail, but finally settled with the following, more or less, which works fine:

plugins {
    id 'base'
}

repositories {
    mavenCentral()
}

// add some attributes to a configuration so that it resolves Java dependencies correctly
def withJavaAttributes = { config ->
        config.attributes {
            attribute Attribute.of("org.gradle.usage", String), "java-runtime"
            attribute Attribute.of("org.gradle.jvm.environment", String), "standard-jvm"
        }
}

configurations {
    withJavaAttributes brokenGuava {
        resolutionStrategy {
            failOnVersionConflict()
        }
    }
}

tasks.register('copyLibs', Copy) {
    from configurations.brokenGuava
    into 'libs'
}

tasks.register('cleanLibs', Delete) {
    delete 'libs/'
}

tasks.clean.dependsOn 'cleanLibs'

dependencies {
    brokenGuava 'com.google.code.gson:gson:2.11.0', {
        // conflicting versions, not needed at runtime anyway
        exclude module: 'error_prone_annotations'
    }

    brokenGuava 'com.google.guava:guava:33.2.1-jre', {
        exclude module: 'error_prone_annotations'
    }
}

Tested with Gradle 8.