-
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
Use Gradle module available-at tag instead of files for redirecting jre vs android consumers #7154
Comments
What would work better in this case is to use If guava-32.1.3-android.module instead has this:
signature verification succeeds. it also reduces redundancy of declared dependencies. |
@jjohannes since you added the Gradle module metadata support in the first place |
Guava now uses Gradle module metadata for resolving android vs jre artifacts so importMaven resolver needs to start specifying TARGET_JVM_ENVIRONMENT_ATTRIBUTE Additionally, found a bug in how the metadata is structured: google/guava#7154 Test: ./development/importMaven/importMaven.sh com.google.guava:guava:32.1.3-jre --redownload Change-Id: I4e59daff0bbc6451336c2d59709aa78bf10a19ae
Note that available-at matches how Kotlin Multiplatform artifacts handle disambiguation in gradle module metadata. See https://repo1.maven.org/maven2/com/squareup/okio/okio/3.9.0/okio-3.9.0.module as an example |
Thank you for investigating and sharing @liutikas. I am afraid that The difference between how Guava does variants compared to how it is done elsewhere (e.g. Kotlin Multiplatform) is that Guava uses different versions of the same component to represent the variants. (1) In Guava you have
(2) If Guava would represent the android variant as classified Jar Ideally, you would use just multiple artifacts with classifiers. That what I would do for a Java library today if I would publish it with two variants for "jre" and "android". (And the metadata we have now is very close to it, just that it hast to point into the other version folder –
(3) If Guava would represent its variants as Kotlin Multiplatform does If there is a specific reason to have each variant in a separate component (like in Kotlin Multiplatform) you can do that and use
I can still emphasize with why solution (1) was chosen years ago. It is "misusing" the version conflict resolution of the build tools to make sure that never both variants are selected together. Today, Gradle is "variant aware" and solution (2) would be better and the metadata we have tries to get to that as close as possible. (But even if it would be reinvented today, what about Maven which does not have such variant awareness? yet?) In the current setup (1), we cannot use
|
If I add the following diff to https://github.com/liutikas/guava-signature-repro repro project
and the local copy maven has the following diff
both However, I do see that the spec does seem to forbid this :/ |
@liutikas And the version specific entry in |
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 get32.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
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
Expected Behavior
Signatures are valid and everything is validated without allowlisting
Actual Behavior
Failure seen:
Packages
No response
Platforms
Android
Checklist
The text was updated successfully, but these errors were encountered: