KEMBAR78
Fix resolution of Android/AAR artifacts with Gradle resolver by smocherla-brex · Pull Request #1395 · bazel-contrib/rules_jvm_external · GitHub
Skip to content

Conversation

@smocherla-brex
Copy link
Contributor

@smocherla-brex smocherla-brex commented Jul 3, 2025

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 runtimeClasspath configuration only resolves artifacts for the JVM platform with gradle (because we have apply 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 by runtimeClasspath, 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

bazel query @regression_testing_gradle//:androidx_compose_foundation_foundation_layout_android --output=build
# /private/var/tmp/_bazel_smocherla/536b5c8af4e86fad57fc24f39380ac8a/external/_main~maven~regression_testing_gradle/BUILD:392:11
aar_import(
  name = "androidx_compose_foundation_foundation_layout_android",
  visibility = ["//visibility:public"],
  tags = ["maven_coordinates=androidx.compose.foundation:foundation-layout-android:1.5.0-beta01@aar", "maven_repository=https://maven.google.com", "maven_sha256=4984eb1b708b9060fb6e70455cf245f7b9604909fca7895c15ebfd8bfd678309", "maven_url=https://maven.google.com/androidx/compose/foundation/foundation-layout-android/1.5.0-beta01/foundation-layout-android-1.5.0-beta01.aar"],
  applicable_licenses = ["@regression_testing_gradle//:androidx_compose_foundation_foundation_layout_android_package_info"],
  deps = ["@regression_testing_gradle//:androidx_annotation_annotation", "@regression_testing_gradle//:androidx_compose_runtime_runtime", "@regression_testing_gradle//:org_jetbrains_kotlin_kotlin_stdlib_common"],
  aar = "@regression_testing_gradle//:androidx/compose/foundation/foundation-layout-android/1.5.0-beta01/foundation-layout-android-1.5.0-beta01.aar",
)
# Rule androidx_compose_foundation_foundation_layout_android instantiated at (most recent call last):
#   /private/var/tmp/_bazel_smocherla/536b5c8af4e86fad57fc24f39380ac8a/external/_main~maven~regression_testing_gradle/BUILD:392:11 in <toplevel>

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.

@cheister
Copy link
Collaborator

cheister commented Jul 3, 2025

Thanks for the PR! LGTM.

Do you mind uncommenting the "androidx.compose.foundation:foundation-layout:1.5.0-beta01" dep in the regression_test_gradle declared in the WORKSPACE file as well?

And checking the formatting by running bazel run //scripts:format ?

@smocherla-brex
Copy link
Contributor Author

Do you mind uncommenting the "androidx.compose.foundation:foundation-layout:1.5.0-beta01" dep in the regression_test_gradle declared in the WORKSPACE file as well?

And checking the formatting by running bazel run //scripts:format ?

Updated.

Copy link
Collaborator

@shs96c shs96c left a 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?

@shs96c shs96c merged commit ac628a7 into bazel-contrib:master Jul 3, 2025
7 checks passed
@smocherla-brex smocherla-brex deleted the smocherla/detached-cfg branch July 3, 2025 14:29
shs96c added a commit to jin/rules_jvm_external that referenced this pull request Jul 4, 2025
* 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 {
Copy link

@acecilia acecilia Aug 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you missed to uncomment the test from the bottom part of the file, here

I am fixing it here

Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants