-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bazel: Export deps from maven stand-in targets #9780
Conversation
If an artifact on Maven Central exposes a type from gRPC on its API surface, then consumers of that artifact need that gRPC API in the compile classpath. Bazel handles this by making hjars for transitive dependencies, but if the dependencies are runtime_deps then Bazel won't generate hjars containing the needed symbols. We don't export netty-shaded because the classes already don't match Maven Central. If an artifact on Maven Central is exposing a netty-shaded class on its API surface, it wouldn't work anyway since the class simply doesn't exist for the Bazel build. Fixes grpc#9772
"@io_netty_netty_handler//jar", | ||
"@io_netty_netty_handler_proxy//jar", | ||
"@io_netty_netty_resolver//jar", | ||
"@io_netty_netty_transport//jar", | ||
"@io_netty_netty_transport_native_unix_common//jar", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving this from line 23 - is that necessary? What does it achieve?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It puts them in alphabetical order which makes maintenance easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Buildifier did it because it was out-of-order. Somehow it had been missed before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM: left one comment about what might be an unneeded change
If an artifact on Maven Central exposes a type from gRPC on its API surface, then consumers of that artifact need that gRPC API in the compile classpath. Bazel handles this by making hjars for transitive dependencies, but if the dependencies are runtime_deps then Bazel won't generate hjars containing the needed symbols.
We don't export netty-shaded because the classes already don't match Maven Central. If an artifact on Maven Central is exposing a netty-shaded class on its API surface, it wouldn't work anyway since the class simply doesn't exist for the Bazel build.
Fixes #9772