MODULE.bazel doesn't define @maven repository

[comius]

trafficstars

What version of protobuf and what language are you using?

Version: 27.1 (and at head) Language: Bazel 7+ with bzlmod enabled

What did you do?

Steps to reproduce the behavior:

$ bazel --version
bazel 7.2.0
$ touch WORKSPACE.bzlmod   # disables WORKSPACE file for bzlmod
$ bazel build --enable_bzlmod //java/util

What did you expect to see Successful build.

What did you see instead?

ERROR: no such package '@@[unknown repo 'maven' requested from @@]//': The repository '@@[unknown repo 'maven' requested from @@]' could not be resolved: No repository visible as '@maven' from main repository
ERROR: /usr/local/google/home/ilist/src/protobuf/java/util/BUILD.bazel:8:13: no such package '@@[unknown repo 'maven' requested from @@]//': The repository '@@[unknown repo 'maven' requested from @@]' could not be resolved: No repository visible as '@maven' from main repository and referenced by '//java/util:util'
ERROR: Analysis of target '//java/util:util' failed; build aborted: Analysis failed
INFO: Elapsed time: 0.359s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
ERROR: Build did NOT complete successfully

Anything else we should know about your project / environment

This problem practically prevents protobuf to be used as a transitive dependency with bzlmod.

[comius]

cc @alexeagle @fmeum @meteorcloudy

[meteorcloudy]

I also hit this in: https://github.com/bazelbuild/bazel/issues/22719

One question is, should grpc use the default @maven repo so that it uses the same set of dependencies as the root project or it should define its own. /cc @shs96c

[meteorcloudy]

Another question is should protobuf users even depend on //java/util? Or they should just fetch the protobuf jars with rules_jvm_external?

[comius]

Users should use java_proto_library and not the //java/util directly.

But protobuf with bzlmod doesn’t work because it needs //java/util for itself.

I’ve hit the problem migrating Bazel to latest protobuf repo

[shs96c]

@meteorcloudy, the rule of thumb is "the only time a ruleset should contribute to the maven workspace is iff the user has to use these specific versions in their own apps"

In contrib_rules_jvm, we need to link the test runner against junit5, but we don't want to force a user to pick the version we do, so we jump through a few hoops to make sure we don't expose the junit5 dep to the user, and then require them to add the junit deps to their own tests. At runtime, we sniff for required dependencies, so we can offer a helpful error message.

A similar approach for things like protobuf (and presumably java-grpc) of asking people to manually add a single maven coordinate to their own project would be the ideal thing to do.

[shs96c]

IME, people who are depending on libraries that depend on protobuf often already have a copy of the required jar on their classpath.

[alexeagle]

I think it's a design mistake for a repo to provide both a Bazel module and language-specific libraries. I suggest dropping Maven and let the user give the label of the protobuf runtime like toolchains_protoc. I can give more details if you're interested

[comius]

I think it's a design mistake for a repo to provide both a Bazel module and language-specific libraries. I suggest dropping Maven and let the user give the label of the protobuf runtime like toolchains_protoc. I can give more details if you're interested

I don’t see how this is relevant, because the @maven dependencies are external to protoc. Delete workspace file and you can’t build a runtime .jar in this case. So alternatives are to get guava and other libraries form another bzlmod repo or vendor them. I think using maven is a good approach here.

It’s certainly a design decision to have rules and toolchains together in the same module/repository. Let’s discuss this somewhere else and not in a bug report.

[joca-bt]

Using the name @maven can result in surprising errors for users, see https://github.com/bazelbuild/rules_jvm_external/issues/1168 for an example. I think in such situations the repo should use a different name for the maven repository to avoid clashing with users.