Summary
java_grpc_library.bzl hardcodes its runtime deps on
@io_grpc_grpc_java//stub (and @io_grpc_grpc_java//protobuf),
whose BUILD files internally reach into the shared @maven repo
provided by rules_jvm_external. This makes it impossible for
downstream modules to consume java_grpc_library-generated targets
via BCR without the consumer's root MODULE.bazel blessing grpc-java
(and transitively protobuf) as contributors to @maven:
maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven")
maven.install(known_contributing_modules = ["grpc-java", "protobuf"])
use_repo(maven, "maven")
Without that boilerplate, analysis of any consumer target that
transitively hits java_grpc_library-generated targets fails with:
ERROR: no such target '@@rules_jvm_external++maven+maven//:io_netty_netty_handler':
target 'io_netty_netty_handler' not declared in package '' defined by
.../external/rules_jvm_external++maven+maven/BUILD
ERROR: .../external/grpc-java+/stub/BUILD.bazel:4:13: no such target
'@@rules_jvm_external++maven+maven//:org_codehaus_mojo_animal_sniffer_annotations':
target 'org_codehaus_mojo_animal_sniffer_annotations' not declared in package ''
... referenced by '@@grpc-java+//stub:stub'
known_contributing_modules is only honored for the root module, so
the bless cannot be pushed down — every consumer has to repeat it.
This also blocks consumers who use isolated maven repos (the pattern
rules_jvm_external recommends for library modules)
from fully escaping @maven.
Reproducer
# MODULE.bazel
module(name = "consumer", version = "0")
bazel_dep(name = "grpc-java", version = "1.78.0")
bazel_dep(name = "protobuf", version = "33.5")
bazel_dep(name = "rules_jvm_external", version = "6.10")
# BUILD.bazel — any target that transitively depends on a
# java_grpc_library-generated target via @grpc-java//stub fails.
bazel build @grpc-java//netty:netty fails with the @maven errors
above. Adding the known_contributing_modules bless makes it pass.
Proposed fix
Expose the stub/protobuf deps as rule attributes with sensible
defaults, so callers can override them to point at their own maven
artifacts:
java_grpc_library(
name = "...",
srcs = [...],
deps = [...],
# New, defaults to @io_grpc_grpc_java targets:
grpc_stub_dep = "@io_grpc_grpc_java//stub",
grpc_protobuf_dep = "@io_grpc_grpc_java//protobuf",
)
Consumers using isolated maven repos could then pass
@their_maven//:io_grpc_grpc_stub and bypass the shared @maven
entirely.
Context
Hitting this while trying to publish 4ward
(a P4 simulator) to the Bazel Central Registry. Every consumer of
4ward's P4Runtime gRPC server target currently has to repeat the
known_contributing_modules boilerplate in their root MODULE.bazel.
Summary
java_grpc_library.bzlhardcodes its runtime deps on@io_grpc_grpc_java//stub(and@io_grpc_grpc_java//protobuf),whose BUILD files internally reach into the shared
@mavenrepoprovided by
rules_jvm_external. This makes it impossible fordownstream modules to consume
java_grpc_library-generated targetsvia BCR without the consumer's root
MODULE.bazelblessing grpc-java(and transitively protobuf) as contributors to
@maven:Without that boilerplate, analysis of any consumer target that
transitively hits
java_grpc_library-generated targets fails with:known_contributing_modulesis only honored for the root module, sothe bless cannot be pushed down — every consumer has to repeat it.
This also blocks consumers who use isolated maven repos (the pattern
rules_jvm_external recommends for library modules)
from fully escaping
@maven.Reproducer
bazel build @grpc-java//netty:nettyfails with the@mavenerrorsabove. Adding the
known_contributing_modulesbless makes it pass.Proposed fix
Expose the stub/protobuf deps as rule attributes with sensible
defaults, so callers can override them to point at their own maven
artifacts:
Consumers using isolated maven repos could then pass
@their_maven//:io_grpc_grpc_stuband bypass the shared@mavenentirely.
Context
Hitting this while trying to publish 4ward
(a P4 simulator) to the Bazel Central Registry. Every consumer of
4ward's P4Runtime gRPC server target currently has to repeat the
known_contributing_modulesboilerplate in their rootMODULE.bazel.