Isolate bazel_worker_java dependencies

[Bencodes]

We see lots of warnings in our console builds because of these rules relying on the default rules_jvm_external maven namespaces.

The solution here would be to move these maven dependencies into their own namespace.

(15:01:37) DEBUG: /private/var/tmp/_bazel_blee/499a001013731d09bffd82f8601a3161/external/rules_jvm_external+/private/extensions/maven.bzl:155:14: The maven repository 'maven' is used in two different bazel modules, originally in 'protobuf' and now in 'bazel_worker_java'
(15:01:37) DEBUG: /private/var/tmp/_bazel_blee/499a001013731d09bffd82f8601a3161/external/rules_jvm_external+/private/extensions/maven.bzl:155:14: The maven repository 'maven' is used in two different bazel modules, originally in 'protobuf' and now in 'bazel_worker_java'
(15:01:37) DEBUG: /private/var/tmp/_bazel_blee/499a001013731d09bffd82f8601a3161/external/rules_jvm_external+/private/extensions/maven.bzl:155:14: The maven repository 'maven' is used in two different bazel modules, originally in 'protobuf' and now in 'bazel_worker_java'
(15:01:37) DEBUG: /private/var/tmp/_bazel_blee/499a001013731d09bffd82f8601a3161/external/rules_jvm_external+/private/extensions/maven.bzl:155:14: The maven repository 'maven' is used in two different bazel modules, originally in 'protobuf' and now in 'bazel_worker_java'
(15:01:37) DEBUG: /private/var/tmp/_bazel_blee/499a001013731d09bffd82f8601a3161/external/rules_jvm_external+/private/extensions/maven.bzl:155:14: The maven repository 'maven' is used in two different bazel modules, originally in 'protobuf' and now in 'bazel_worker_java'
(15:01:37) DEBUG: /private/var/tmp/_bazel_blee/499a001013731d09bffd82f8601a3161/external/rules_jvm_external+/private/extensions/maven.bzl:155:14: The maven repository 'maven' is used in two different bazel modules, originally in 'protobuf' and now in 'bazel_worker_java'

And as a result of using the default shared namespace:

(15:01:41) DEBUG: /private/var/tmp/_bazel_blee/499a001013731d09bffd82f8601a3161/external/rules_jvm_external+/private/rules/coursier.bzl:774:18: Found duplicate artifact versions
    org.mockito:mockito-core has multiple versions 4.3.1, 5.4.0
    com.google.truth:truth has multiple versions 1.1.2, 1.4.0
    com.google.code.gson:gson has multiple versions 2.8.9, 2.10.1
    com.google.errorprone:error_prone_annotations has multiple versions 2.5.1, 2.23.0
    com.google.guava:guava has multiple versions 32.0.1-jre, 33.0.0-jre

[meteorcloudy]

We could use a different maven namespace for this module, but wouldn't there be risks of conflict classes? If your target A depends on bazel-worker-api, which depends on guava, and your target also directly depends on a different version of guava from another maven namespace.

@jin @shs96c What is the recommended best practice?

[jin]

Yes, care has to be taken when using multiple namespaces (https://github.com/bazel-contrib/rules_jvm_external?tab=readme-ov-file#multiple-maven_install-declarations-for-isolated-artifact-version-trees) that the dep classes from the different namespaces don't make it into the same top level target, i.e. enforcing the one-version rule at the target level.

Is there warning too verbose? We can consider improving it if that's the main concern.

[Bencodes]

Is there warning too verbose? We can consider improving it if that's the main concern.

The messages are definitely verbose. Any time you run a Bazel command where it has to bring up the server for the first time, the console gets hit with a flood of warnings from rules_jvm_external all caused by this worker using the default namespace. I only pasted a subset of them above as an example.

[shs96c]

This can be fixed by updating to v29.1 of protobuf. Relevant issues are protocolbuffers/protobuf#19477 (comment) and protocolbuffers/protobuf#19451 (comment)

[meteorcloudy]

The problem also exists in this repo:

bazel-worker-api/java/MODULE.bazel

Line 39 in 3dfa382

use_repo(maven, "maven")

Should we also rename it?

[shs96c]

I would suggest doing so if the repos are independent of each other.

[meteorcloudy]

Say if I have a target:

java_binary(
  name = "foo",
  srcs = ["Foo.java"],
  deps = [
     "@bazel_worker_java//src/main/java/com/google/devtools/build/lib
/worker:work_request_handlers",
     "@maven//:com_google_guava_guava",
  ],
)

If we rename the maven install for bazel_woker_java, wouldn't two different guava versions ended up in foo's transitive dependencies? Is that in general fine with Java?

[jin]

There are two options:

1. bazel_worker_java contributes its own jar deps into the @maven namespace. This will contribute to the users jars for resolving into a single version per dep.
2. bazel_worker_java uses its own namespace, and make sure that the targets it exposes do not pass on the transitive runtime classpath to the user.

I don't think renaming is the right solution, because

bazel-worker-api/java/src/main/java/com/google/devtools/build/lib/worker/BUILD.bazel

Line 6 in 3dfa382

name = "work_request_handlers",

is meant to be depended upon by users' java tooling targets, which means :work_request_handlers's deps should also be contributed into default user @maven namespace, so that there's only one resolved version per jar in the runtime classpath of those worker tools.

I'll work on a separate patch to reduce the noise.

[meteorcloudy]

@jin Thanks for the clarification!

[jin]

bazel-contrib/rules_jvm_external#1295 will fix the noisy logs.

[Bencodes]

An alternative solution here would be to isolate the worker maven dependencies into it's own known maven repository, and then document how consumers of these rules can override the actual versions to match the versions that they define in their projects.

Example:

maven.override(
    name = "worker_maven",
    coordinates = "com.google.protobuf:protobuf-java",
    target = "@maven//:com_google_protobuf_protobuf_java",
)