protocolbuffers
Clarification on protobuf_maven namespace change and transitive dependency resolution
Hi all,
We’ve recently upgraded to the latest version of protobuf, and we noticed an unexpected side effect caused by the change in the Maven repository name from maven to protobuf_maven. Specifically, this seems to have impacted our dependency resolution when using rules_jvm_external, and I wanted to better understand the rationale behind this change and whether we might be approaching our setup incorrectly.
To give some context: rules_jvm_external allows projects to declare and pin their own Maven dependencies centrally in a maven_install block, which can then be referenced across targets. This ensures consistency in versions and avoids surprises from transitive dependencies. However, since protobuf now declares its own maven_install under the protobuf_maven namespace, we no longer have visibility or control over overlapping dependencies declared there. As a result, even if we explicitly define and version certain dependencies in our own maven_install, they can be silently overridden by those declared by protobuf_maven, especially for targets that transitively use protobuf.
To make this more concrete: suppose we are building target A, which depends on:
- our own dependency B (declared via our maven_install)
- and protobuf (directly or transitively, i.e. dependency C)
If dependency B in turn depends on dependency X, and dependency X is also brought in (perhaps at a different version) by protobuf_maven, then Bazel appears to resolve it using the version from protobuf_maven, even though we’ve declared a different version ourselves. In our case, this led to hard-to-diagnose issues where transitive dependencies like gson were pulled in by protobuf at incompatible versions, silently causing breakages.
I understand that there are already several tickets advocating for protobuf to not use the generic maven namespace, and instead adopt a dedicated one (which it now does). I see the reasoning behind this: shared use of a generic namespace like maven can lead to collisions when different modules pull in their own artifacts. However, in our case, the opposite seems true: by having protobuf isolate its dependencies in a separate namespace, we’ve lost the ability to unify and control dependency resolution across our workspace.
So I’m hoping to understand:
- Is there a recommended way to handle scenarios like the above which share overlapping dependencies, yet they are managed by two different namespaces?
- Can one "alias" the deps from protobuf_maven to the ones in our own maven namespace?
I’m genuinely trying to understand the tradeoffs here, so I’m happy to be corrected if we’re missing a better way to align dependency versions.
Thanks.
Related issues in favour of the namespace change:
- https://github.com/protocolbuffers/protobuf/issues/17117
- https://github.com/protocolbuffers/protobuf/issues/16839
- https://github.com/protocolbuffers/protobuf/issues/20674
What version of protobuf and what language are you using? Version: v30.2
Thanks for raising this! I think this is may be more of a question for rules_jvm_external maintainers for guidelines on what the best practices should be for situations like this. I believe the original move to protobuf_maven custom namespace was motivated by this comment from maintainers: https://github.com/bazel-contrib/rules_jvm_external/issues/916#issuecomment-1645527584.
https://github.com/bazel-contrib/rules_jvm_external/issues/916 seems to still be an open thread on this and seems to be somewhat inconclusive on the recommended best practices here. Will follow-up here, but feel free to chime in here as well.
I also believe renaming the maven install name to protobuf_maven is probably a mistake, see https://github.com/bazel-contrib/rules_jvm_external/issues/916#issuecomment-3045506487
