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:
What version of protobuf and what language are you using?
Version: v30.2
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:
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:
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:
mavenas the repo name causes duplicate warnings when using bzlmod #16839What version of protobuf and what language are you using?
Version: v30.2