Commit Graph

4 Commits

Author SHA1 Message Date
Eric Anderson c606519a5d bazel: Support maven_install
maven_install is strongly superior to previous forms of grabbing dependencies
from Maven as it computes the appropriate versions to use from the full
transitive dependencies of all libraries used by an application. It also has
much less boilerplate and includes dependencies with generated targets.

In the future we will drop the jvm_maven_import_external usages and require
maven_install, at which point we can swap to using the `@maven' repository and
no longer depend on compat_repositories.

Fixes #5359
2019-12-30 12:08:42 -08:00
Eric Anderson 024a46bd11
bazel: Support --incompatible_load_proto_rules_from_bzl
This flag will be enabled by default in Bazel 1.0

Since I changed the grpc-proto repo version for Bazel, I also synced the
protos.
2019-10-09 14:46:17 -07:00
Eric Anderson 80c3c992a6 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-16 21:45:40 -07:00
ZHANG Dapeng 3202fcc7d9
examples: move TLS example to a separate project 2018-12-06 12:03:25 -08:00