`rules_android_maven` Should Not Force Large Live Coursier Resolution

[bc-lee]

Summary

rules_android@0.7.1 triggers large live Coursier resolution (no lock file), causing slow, fragile builds and frequent timeouts:

Error while fetching artifact with coursier: Timed out

Repro

Repo: https://github.com/bc-lee/rules-android-maven-live-resolution-repro

Run:

RJE_VERBOSE=true USE_BAZEL_VERSION=9.0.2 bazelisk build \
  @rules_android//src/tools/java/com/google/devtools/build/android/r8:r8

(RJE_VERBOSE=true to expose Coursier behavior)

• 60be301: fails with timeout
• c445ef1: success with lock file

Root Cause

rules_android_maven defines a large maven.install(...) (50+ artifacts) but does not enable its lock file, forcing:

• large live coursier fetch
• duplicate resolution (rules_android_maven, bazel_worker_maven)
• heavy network traffic before actual build

Impact

• slow builds
• network-sensitive / flaky (timeouts)
• problematic in CI or restricted environments

Suggested Fix

Enable the existing lock file:

maven.install(
    name = "rules_android_maven",
    lock_file = "//:rules_android_maven_install.json",
    ...
)

Evidence

With only this change:

-    # lock_file = "//:rules_android_maven_install.json",
+    lock_file = "//:rules_android_maven_install.json",

the same build succeeds reliably.

Workaround

Downstream patch:

+    lock_file = "//:rules_android_maven_install.json",

(Optionally resolver = "gradle")

[Bencodes]

rules_android should definitely handle this (#407), but you can also manually pin these from your project by defining a maven repo that shares the same rules_android_maven namespace and define the lock file there.

[ted-xie]

We've disabled the Maven lockfile (we used to have one) for two reasons.

1. Dependency churn while rapidly iterating was painful. Note that this repository is an export of code from our monorepo; we don't use git, bzlmod, or any remote deps for internal development.
2. In the run-up to the Bazel 8 release, we actually saw a performance degradation for cold builds with the lock file enabled on internal CI. Yes, it's counterintuitive. That may have something to do with the particular type of machine we use for internal CI, but there was clear evidence that the lock file was net detrimental for internal development velocity.