-
Notifications
You must be signed in to change notification settings - Fork 10.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gradle Metadata of 32.1.0 has a SNAPSHOT version number #6612
Comments
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 I'll update the release notes, delete the old script, update the new script, and publish a new release. |
… to update the Gradle Metadata. In cl/544108700, I'd changed the old release script but not the internal one. Fixes #6612 RELNOTES=Fixed the broken Gradle Metadata published with 32.1.0. PiperOrigin-RevId: 544635125
OK, 32.1.1 is published, and I ran a couple tests beforehand that suggest this problem should be fixed:
|
Thanks for following up so quick! The 32.1.1 module files look correct to me. |
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? `
` |
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 " |
@bjwyse are you running Gradle 6.x? You need to add something like this to a place where you configure the Java plugins:
Starting with Gradle 7.0, Gradle automatically supports the @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. |
…ring Guava releases. And make that process a little faster and more hygienic. (I see no reason to expect us to [get the Gradle setup wrong](#6612) again, but it would be quite embarrassing if we did....) RELNOTES=n/a PiperOrigin-RevId: 544680176
Thanks, @jjohannes. I've updated the release notes to mention this. |
…ring Guava releases. And make that process a little faster and more hygienic. (I see no reason to expect us to [get the Gradle setup wrong](#6612) again, but it would be quite embarrassing if we did....) RELNOTES=n/a PiperOrigin-RevId: 544737095
Hi @cpovirk, 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! |
Hi, I am facing issue
|
Hi @ashwinibairyruge - a fundamental flaw in this setup is that the
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:
|
@tanmaymanolkar1 your issue is similar. MapDB should not publish dynamic version dependencies. For example, they should use 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) |
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: |
@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 When the 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 |
We're seeing the same issue - is there an ETA on a fix? |
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
|
@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:
|
Assuming you are on Gradle 6 @johannesup, did you add #6612 (comment)? |
@deepamalik18 This part of the message...
tells you that your run Gradle 6.7.1. Maybe your CI configuration picks a different version than it is supposed to. |
@rochish-suresh thanks for sharing additional information. In your error logs it says at some point:
And afterwards
I think this means that you define a Configuration called
I can't be more precise without seeing the custom build logic of your project. |
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? |
Hi @jjohannes, I am on gradle 7.5.1 and I am still getting this error Execution failed for task ':LinuxBroker:compileKotlin'.
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. |
@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:
Do that in the |
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.
You can switch between working and non-working in
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. |
Also in "All of them match the consumer attributes," here is a Stack Overflow question that I'm not sure how to help with. |
I digged a bit deeper in my sample project guava_issue_6612: When the equivalent of attribute
Finally, when the
Maybe this helps someone... |
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 It also looks to me as if |
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? |
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.
|
@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. |
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:
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. |
@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 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. |
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 |
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 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. |
I am very sorry @cpovirk but the Gradle Metadata just published is broken. If you look at these two files:
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.
The text was updated successfully, but these errors were encountered: