Duplicate maven repositories when importing bazel_deps that use maven.install

[aarontsharp]

When using maven.install via bzlmod in the root module, any bazel_dep which also uses maven.install (with the default repository name) can create duplicate artifacts/conflicts.

For instance, when including a bazel_dep for protobuf 21.7 , the following message is logged:

The maven repository 'maven' is used in two different bazel modules, originally in '' and now in 'protobuf'

This happens because protobuf does a maven.install using maven as the repository name pinning various common dependencies

This is maybe benign in and of itself, but it can create artifact conflicts. For example, pinning different versions of mockito/guava/etc to the root module, the following messages are logged:

Found duplicate artifact versions
    com.google.guava:guava has multiple versions 32.0.0-jre, 31.1-jre
    org.mockito:mockito-core has multiple versions 5.3.1, 4.3.1

It's possible to work around this by using a separate name for maven.install, but it is quite annoying (since you need to set repository_name everywhere) and likewise incredibly difficult to understand where these duplicates were introduced. In my case, I wasn't even directly importing protobuf in my root module, but transitively through another bazel_dep, so this was incredibly confusing.

Is there a better way to understand and resolve these conflicts?

[meteorcloudy]

@shs96c Are maven.install with the same name resolved together or separately? How do you recommend to address the warning message?

/cc @Wyverald

[shs96c]

All the repositories with the same name are resolved together. This allows rulesets to contribute to the user’s jars easily and efficiently. This also implies that the default “maven” name should only be used for this purpose. TBH, relying on the “maven” namespace being as you declared it in your workspace file for anything than the top-level project was always a risky thing to do. Bzlmod has made that more obvious. Inter-ruleset dependencies have to be handled this way because constants cannot be loaded in a MODULE.bazel file. If a rulesets wants to have dependencies only it uses (for example for custom tooling) then it’s recommended that they declare a custom namespace for themselves and depend upon that. If you’d like to see an example, then “contrib_rules_jvm” does this. On 21 Jul 2023, at 15:08, Yun Peng @.***> wrote: @shs96c Are maven.install with the same name resolved together or separately? How do you recommend to address the warning message? /cc @Wyverald

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[Ubehebe]

I just ran into this too, and I think it's specifically a problem with the protobuf module. Other modules take care to instantiate their maven artifacts with different names to avoid polluting the default "maven" name:

• rules_jvm_external itself uses the name rules_jvm_external_deps
• rules_kotlin uses the name kotlin_rules_maven

Is there a good reason why protobuf should make its internal java dependencies visible in this way? If not, we should ask the protobuf module maintainers to change it.

[meteorcloudy]

Not really, it was added as a patch file at https://github.com/bazelbuild/bazel-central-registry/blob/918ea9ff0a8c5d3f8719c84c2109c5a25631fc47/modules/protobuf/21.7/patches/add_module_dot_bazel.patch#L37, we can make a BCR patch version for protobuf to fix this issue.

[luangong]

I also ran into this issue and I agree with @meteorcloudy. Let’s go and make the patch to protobuf in BCR 💪

[andrew-otiv]

I just ran into this too trying to build https://github.com/entur/schema2proto in bazel. Thanks for working on this!

Update: No longer urgent for us since we ended up disabling bzlmod.