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/api/BUILD.bazel

17 lines
590 B
Python
Raw Normal View History

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
java_library(
name = "api",
srcs = glob([
"src/main/java/**/*.java",
context, all: move Context classes to grpc-api (#10313) * context, all: move Context classes to grpc-api clean up grpc-context since it has no source code: only add dep on grpc-api add exclusion for all transitive deps of grpc-api - only guava exclude grpc-context as a dependency from grpc-alts because all context code is in grpc-api now api: 1.7 as target Java version for Context source-set of grpc-api * core, census: fix the issues with android project pulling in old grpc-context version * api,context: make changes to bazel build files to account for context code moving from context to api
2023-06-29 09:28:30 +08:00
"src/context/java/**/*.java",
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
]),
Use @DoNotCall for static methods in Builders that throw Since static methods are pseudo-inherited by Builder implementations but are trivially accidentally used, we re-define static methods in each builder to make them behave more like the caller would expect. However, not all the methods actually work; some just throw because the caller was certainly not getting what they would expect. Annotating with `@DoNotCall` can expose the problems at compile time instead of runtime. While `@Deprecated` would also be an option, it is a bit harder to figure out the ramifications and whether we want to go that route. This change was suggested by a lint tool for XdsServerBuilder and it seems appropriate so I applied it to the other similar cases I could find.
2021-05-13 01:12:52 +08:00
javacopts = ["-Xep:DoNotCall:OFF"], # Remove once requiring Bazel 3.4.0+; allows non-final
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
visibility = ["//visibility:public"],
deps = [
"@com_google_code_findbugs_jsr305//jar",
Use @DoNotCall for static methods in Builders that throw Since static methods are pseudo-inherited by Builder implementations but are trivially accidentally used, we re-define static methods in each builder to make them behave more like the caller would expect. However, not all the methods actually work; some just throw because the caller was certainly not getting what they would expect. Annotating with `@DoNotCall` can expose the problems at compile time instead of runtime. While `@Deprecated` would also be an option, it is a bit harder to figure out the ramifications and whether we want to go that route. This change was suggested by a lint tool for XdsServerBuilder and it seems appropriate so I applied it to the other similar cases I could find.
2021-05-13 01:12:52 +08:00
"@com_google_errorprone_error_prone_annotations//jar",
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
"@com_google_guava_failureaccess//jar", # future transitive dep of Guava. See #5214
"@com_google_guava_guava//jar",
"@com_google_j2objc_j2objc_annotations//jar",
],
)