-
-
Notifications
You must be signed in to change notification settings - Fork 274
Fix resolution of Android/AAR artifacts with Gradle resolver #1395
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
Fix resolution of Android/AAR artifacts with Gradle resolver #1395
Conversation
|
Thanks for the PR! LGTM. Do you mind uncommenting the And checking the formatting by running |
Updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests pass, and the code makes sense. LGTM! Thank you for continuing to make this work.
I wonder how Gradle copes with this normally?
* master: (39 commits) Fix resolution of Android/AAR artifacts with Gradle resolver (bazel-contrib#1395) fail_if_repin_required is now True by default and minor improvement to failure message (bazel-contrib#1397) Housekeeping before we release 6.8 (bazel-contrib#1384) Add dll, dylib and so types to maven package mappings (bazel-contrib#1392) [bzlmod] Allow suppressing warning about multiple contributing modules. (bazel-contrib#1393) Use the artifact default values when adding them to a struct and add tests for coursier artifacts that have empty versions provided by BOMs and don't inlcude them in outdated (bazel-contrib#1390) Allow package exclusions and inclusions in javadocs (bazel-contrib#1293) Document well-known issues with `bzlmod` (bazel-contrib#1388) Begin documenting the gradle resolver (bazel-contrib#1389) Run gradle regression tests in CI (bazel-contrib#1385) Modify maven_export to allow exporting zip archives (bazel-contrib#1368) Allow root module's override tags to take precedence over the overridees from transitive deps. (bazel-contrib#1381) Ensure root module artifacts and boms take precedence with warnings (bazel-contrib#1373) Update maven-metadata.xml when publishing locally (bazel-contrib#1369) Add support for gradle resolver (bazel-contrib#1357) Prepare for 6.8 release (bazel-contrib#1380) Remove the Windows `kt_jvm_export` example (bazel-contrib#1383) Avoid spurious warnings about poorly formatted artifact coordinates (bazel-contrib#1374) Flip `fail_if_repin_required` to `True` by default (bazel-contrib#1371) Allow the same coordinate to be overridden in different repos (bazel-contrib#1378) ...
| # # This artifact in maven_install only has gradle metadata, but it should then automatically resolve to the right aar artifact | ||
| # # and make it available | ||
| # bazel query @regression_testing_gradle//:androidx_compose_foundation_foundation_layout_android >> "$TEST_LOG" 2>&1 | ||
| function test_gradle_metadata_is_resolved_correctly_for_aar_artifact { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh good catch, thanks for fixing it.
The AAR integration is broken right now and it turns out AAR resolution in the dependency graph is broken, and for some reason I didn't notice it. This is discussed in #1394 as well.
Essentially, the default
runtimeClasspathconfiguration only resolves artifacts for the JVM platform with gradle (because we haveapply plugin: java). If we want to resolve artifacts (or to be semantically correct dependencies) for other platforms like Android, we either need to configure the android plugin (this is a real rabbit hole with the gradle tooling API I do not recommend) or add additive configurations to resolve them and add to the single dependency graph we produce. I do the latter here with a detached configuration which gradle provides (which is a clean slate). We only apply the detached configuration to dependencies that couldn't be resolved byruntimeClasspath, and then add nodes to the dependency graph from it. After that, we collect other artifacts like AARs from this configuration's ArtifactView. Finally, I had to handle cycles in the formed graph because for some reason we encounter cycles with this approach. After this fix, I'm able to resolve AAR artifacts properly - I uncommented the test case and repinned the lockfile.As you can see, we have the right target here
This solution also offers a good template to resolve Kotlin Multplatform artifacts in the resolver which I hope to get to soon.
Testing: the AAR regression test passes, existing tests also pass.