Skip to content

[bzlmod] java_grpc_library hardcodes @io_grpc_grpc_java//stub, forcing @maven bless-list in consumer MODULE.bazel #12746

@smolkaj

Description

@smolkaj

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions