Bazel breaking for consumers due to pollution of the main maven namespace [30.0 Regression]

[joca-bt]

#20558 reintroduces dependencies into the main maven namespace, this was previously address in 29.1 (#18641, #19477).

Can this be partially reverted or achieved in some other way to not create issues for consumers? See the aforementioned issues for details.

[zhangskz]

I believe this is likely due to a5c906a#diff-6136fc12446089c3db7360e923203dd114b6a1466252e71667c6791c20fe6bdc which spilt our maven dependencies into dev vs local dependencies. Unlike our test/release-specific deps, I think its correct for our actual deps to be included transitively -- can you help us understand why this might be an issue?

i.e.

protobuf/java/util/BUILD.bazel

Lines 17 to 21 in a5c906a

	"@maven//:com_google_code_findbugs_jsr305",
	"@maven//:com_google_code_gson_gson",
	"@maven//:com_google_errorprone_error_prone_annotations",
	"@maven//:com_google_guava_guava",
	"@maven//:com_google_j2objc_j2objc_annotations",

[joca-bt]

When a user imports the protobuf ruleset, all (non-dev-)dependecies in protobuf's MODULE.bazel are imported into their project. In the particular case of rules_jvm_external, by using the default repo name (maven), this will result in the java artifacts required by protobuf to be injected and merged with the java artifacts that the user actually needs. This can create problems for the user, for example, by importing undesired versions of packages. While the user can decide how to resolve these conflicts, these conflicts shouldn't be happening to start with. In case the user is using duplicate_version_warning, this can completely break their build. Most of the dependencies needed by protobuf end up not being required by the user anyway, since they probably only use a subset of protobuf's ruleset features.

Unlike our test/release-specific deps, I think its correct for our actual deps to be included transitively -- can you help us understand why this might be an issue?

Can you explain why do you think this is needed for the user?

Ideally, a ruleset's dependencies should be invisible to the user and not conflict with whatever they are doing. When using rules_jvm_external this is achieved by using different repo names.

You can find more information about this specific problem with protobuf in these issues and the many issues they refer:

• Using maven as the repo name causes duplicate warnings when using bzlmod #16839
• Rename maven to protobuf_maven in MODULE.bazel #18641
• [Bazel] Stop using rules_jvm_external default maven repository name #17117

You can also check your previous fix which addressed this issue #19477.

[daniel-b2c2]

Thanks for reporting this, am having the same issue.

This manifests as a warning when pinning dependencies in bazel. In this case guava is one of the dependencies in conflict.

DEBUG: /private/var/tmp/_bazel_dan/4062fc18797f0c796822bf92f1458040/external/rules_jvm_external~/private/extensions/maven.bzl:351:18: The maven repository 'maven' has contributions from multiple bzlmod modules, and will be resolved together: ["REDACTED", "protobuf"]
DEBUG: /private/var/tmp/_bazel_dan/4062fc18797f0c796822bf92f1458040/external/rules_jvm_external~/private/rules/coursier.bzl:754:18: Found duplicate artifact versions
    com.google.guava:guava has multiple versions 33.4.0-jre, 32.0.1-jre

This had to be downgraded from "error" as it was blocking the build.

Why does guava need to be exposed exactly?