flasn4nt
/
grpc-java
mirror of https://github.com/grpc/grpc-java.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
grpc-java/protobuf/BUILD.bazel

19 lines
529 B
Python
Raw Normal View History

bazel: Use the `artifact` macro for loading maven deps The recommended way to load dependencies from `rules_jvm_external` is to make use of the `@maven` workspace, and the most readable way of doing that is to use the `artifact` macro provides. This removes the need to generate the "compat" namespaces, which `rules_jvm_external` provided for backwards compatibility with older releases. This change also sets things up for supporting `bzlmod`: this requires all workspaces accessed by a library to be named "up front" in the `MODULE.bazel` file. This way, the only repo that needs to be exported is `@maven`, rather than the current huge list.
2024-03-29 05:33:32 +08:00
load("@rules_jvm_external//:defs.bzl", "artifact")
build: Add Bazel java_grpc_library rule Bazel third party dependencies are specified in repositories.bzl which gives the consumer the ability to opt-out of any dependencies they use directly in their own project. Fixes #2756
2017-06-23 04:06:49 +08:00
java_library(
name = "protobuf",
srcs = glob([
"src/main/java/**/*.java",
]),
visibility = ["//visibility:public"],
deps = [
core: Move io.grpc to grpc-api io.grpc has fewer dependencies than io.grpc.internal. Moving it to a separate artifact lets users use the API without bringing in the deps. If the library has an optional dependency on grpc, that can be quite convenient. We now version-pin both grpc-api and grpc-core, since both contain internal APIs. I had to change a few tests in grpc-api to avoid FakeClock. Moving FakeClock to grpc-api was difficult because it uses io.grpc.internal.TimeProvider, which can't be moved since it is a production class. Having grpc-api's tests depend on grpc-core's test classes would be weird and cause a circular dependincy. Having grpc-api's tests depend on grpc-core is likely possible, but weird and fairly unnecessary at this point. So instead I rewrote the tests to avoid FakeClock. Fixes #1447
2019-04-13 08:37:13 +08:00
"//api",
java_grpc_library: Add support for protobuf lite gRPC's protobuf-lite auto-selects between full and lite protobuf based on the value of crosstool_top. If the user is specifying their own --android_crosstool_top, then it will not auto-detect correctly. One day, platforms will fix problems like this, but for the moment it seems we get to live with it.
2018-04-04 06:22:55 +08:00
"//protobuf-lite",
bazel: Remove com_google_protobuf_java This was deprecated with Bazel 0.8.0, which now uses @com_google_protobuf instead. This change will break users that use grpc_java_repositories(omit_com_google_protobuf_java=True), so I've added a custom error message to make the resolution clearer.
2018-01-10 03:02:03 +08:00
"@com_google_protobuf//:protobuf_java",
bazel: Use the `artifact` macro for loading maven deps The recommended way to load dependencies from `rules_jvm_external` is to make use of the `@maven` workspace, and the most readable way of doing that is to use the `artifact` macro provides. This removes the need to generate the "compat" namespaces, which `rules_jvm_external` provided for backwards compatibility with older releases. This change also sets things up for supporting `bzlmod`: this requires all workspaces accessed by a library to be named "up front" in the `MODULE.bazel` file. This way, the only repo that needs to be exported is `@maven`, rather than the current huge list.
2024-03-29 05:33:32 +08:00
artifact("com.google.api.grpc:proto-google-common-protos"),
artifact("com.google.code.findbugs:jsr305"),
artifact("com.google.guava:guava"),
artifact("com.google.j2objc:j2objc-annotations"),
build: Add Bazel java_grpc_library rule Bazel third party dependencies are specified in repositories.bzl which gives the consumer the ability to opt-out of any dependencies they use directly in their own project. Fixes #2756
2017-06-23 04:06:49 +08:00
],
)