Maven dependencies not exposed to Bazel users #9132
Assignees
Labels
Comments
acozzette
added a commit
to acozzette/protobuf
that referenced
this issue
Oct 27, 2021
This commit removes the use of bind() since that function goes against Bazel best practices: https://docs.bazel.build/versions/main/external.html#repository-rules-1 The bind() function basically maps a dependency into //external:, but there is no good reason to do this. By mapping dependencies into //external: and relying on this in our own BUILD files, we're forcing projects that depend on us to do the same. This change also moves our list of required Maven artifacts into protobuf_deps.bzl. This way, projects that depend on us can refer to this list when they invoke maven_install() and automatically pull in all the necesary dependencies. This fixes protocolbuffers#9132.
acozzette
added a commit
to acozzette/protobuf
that referenced
this issue
Oct 27, 2021
This commit removes the use of bind() since that function goes against Bazel best practices: https://docs.bazel.build/versions/main/external.html#repository-rules-1 The bind() function basically maps a dependency into //external, but there is no good reason to do this. By mapping dependencies into //external and relying on this in our own BUILD files, we're forcing projects that depend on us to do the same. The one bind() call that I did leave in place was //:python_headers. This one seems to be doing something complicated I don't fully understand, and I don't want to risk breaking it. This change also moves our list of required Maven artifacts into a constant in protobuf_deps.bzl. This way, projects that depend on us can refer to this list when they invoke maven_install() and automatically pull in all the necesary dependencies. This fixes protocolbuffers#9132.
acozzette
added a commit
that referenced
this issue
Oct 28, 2021
This commit removes the use of bind() since that function goes against Bazel best practices: https://docs.bazel.build/versions/main/external.html#repository-rules-1 The bind() function basically maps a dependency into //external, but there is no good reason to do this. By mapping dependencies into //external and relying on this in our own BUILD files, we're forcing projects that depend on us to do the same. The one bind() call that I did leave in place was //:python_headers. This one seems to be doing something complicated I don't fully understand, and I don't want to risk breaking it. This change also moves our list of required Maven artifacts into a constant in protobuf_deps.bzl. This way, projects that depend on us can refer to this list when they invoke maven_install() and automatically pull in all the necesary dependencies. This fixes #9132.
|
This should be fixed now with #9165, which I plan to release in 3.19.1. In protobuf_deps.bzl we now define a constant |
|
Just confirming that it's fixed for me in 3.19.1 with the new |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of protobuf and what language are you using?
Version: v3.19.0
Language: C++/Java/Kotlin
What operating system (Linux, Windows, ...) and version?
macOS 11.6
What runtime / compiler are you using (e.g., python version or gcc version)
LLVM 12.0.0, Kotlinc 1.5.21
What did you do?
Steps to reproduce the behavior:
@com_google_protobuf//java/util:utilWhat did you expect to see
The build should succeed
What did you see instead?
Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs).
Anything else we should know about your project / environment
gRPC-Java and gRPC-Kotlin (at least) address this problem by exposing the list of dependencies they need: https://github.com/grpc/grpc-java/blob/25022f6846ec1fdd8003789cba32d4ca981c3171/repositories.bzl
The text was updated successfully, but these errors were encountered: