-
Notifications
You must be signed in to change notification settings - Fork 11.1k
Description
Description
com.google.guava:guava has recently started publishing Gradle metadata. There are funky games with supporting JVM vs Android consumers. In Gradle metadata now there are new variants so when asked for com.google.guava:guava:32.1.3-android
, if you are a java project, you get 32.1.3-jre/32.1.3-jre.jar
artifact instead.
this happens in here:
https://repo1.maven.org/maven2/com/google/guava/guava/32.1.3-android/guava-32.1.3-android.module
specifically
"files": [
{
"name": "guava-32.1.3-jre.jar",
"url": "../32.1.3-jre/guava-32.1.3-jre.jar"
}
],
The same is done for -jre version to get android artifact.
This is all good at the compilation level, but when you enable signature verification, gradle gets very confused as it thinks these ../32.1.3-jre/guava-32.1.3-jre.jar
are unsigned.
Example
Repro project https://github.com/liutikas/guava-signature-repro
Expected Behavior
Signatures are valid and everything is validated without allowlisting
Actual Behavior
Failure seen:
* What went wrong:
Execution failed for task ':app:checkDebugDuplicateClasses'.
> Dependency verification failed for configuration ':app:debugRuntimeClasspath'
One artifact failed verification: guava-32.1.3-android.jar (com.google.guava:guava:32.1.3-jre) from repository MavenRepo
If the artifacts are trustworthy, you will need to update the gradle/verification-metadata.xml file. For more on how to do this, please refer to https://docs.gradle.org/8.7/userguide/dependency_verification.html#sec:troubleshooting-verification in the Gradle documentation.
Packages
No response
Platforms
Android
Checklist
- I agree to follow the code of conduct.