Refactor the proto file `helloworld_streaming.proto` because Bazel and Gradle have incompatible base directory for proto imports. Bazel's proto import is relative to WORKSPACE, whereas Gradle proto plugin's is relative to `${sourceSet}/proto/`. In `helloworld_streaming.proto` file, `import helloworld.proto` does not work for Bazel. If `import src/main/proto/helloworld.proto`, that works for Bazel, but Gradle and Maven would fail. Some workarounds are very hacky, so use independent proto without imports instead to avoid this issue.
This bump changelist is applied a bit late with respect to the
1.6.0 branch cut. Look at the 1.6.0 to see the source of truth of
where it was cut. Do not assume it is the commit that precedes
this one.
This commit aligns the naming of the Bazel Maven jars with the names
used by Bazel's migration-tooling project:
https://github.com/bazelbuild/migration-tooling
Unfortunately, we can't fix @com_google_protobuf_java because it's
required by Bazel itself.
Fixes#3328
Class.forName(String) is understood by ProGuard, removing the need for
manual ProGuard configuration and allows ProGuard to rename the provider
classes. Previously the provider classes could not be renamed.
Fixes#2633
## Bazel
If you prefer to use Bazel:
```
(With Bazel v0.4.5 or above.)
$ bazel build :hello-world-server :hello-world-client
$ # Run the server:
$ bazel-bin/hello-world-server
$ # In another terminal run the client
$ bazel-bin/hello-world-client
```
The current check in ServerCallImpl is theoretically unsafe (#3059). Move that check into the stub, and expand the unit tests to cover other interesting edge cases on the server side:
client sends one, but zero requests received at onHalfClose
client sends one, but > 1 requests received at onHalfClose
server sends one, but zero responses sent at onComplete
server sends one, but > 1 responses sent via onNext
fixes#2243fixes#3059
migrated simple tests using `GrpcServerRule`.
Kept the low level in-process channel setup and tear down code for the RouteGuide example to show how users can use in-process directly to set more custom channel builder options when needed.
resolves#2490
Guava 20 introduced some overloading optimizations for Preconditions
that require using Guava 20+ at runtime. Unfortunately, Guava 20 removes
some things that is causing incompatibilities with other libraries, like
Cassandra. While the incompatibility did trigger some of those libraries
to improve compatibility for newer Guavas, we'd like to give the
community more time to work through it. See #2688
At this commit, we appear to be compatible with Guava 18+. It's not
clear if we want to actually "support" 18, but it did compile. Guava 17
doesn't have at least MoreObjects, directExecutor, and firstNotNull.
Guava 21 compiles without warnings, so it should be compatible with
Guava 22 when it is released.
One test method will fail with the upcoming Guava 22, but this won't
impact applications. I made MoreThrowables to avoid using any
known-deprecated Guava methods in our JARs, to reduce pain for those
stuck with old versions of gRPC in the future (July 2018).
In the stand-alone Android apps I removed unnecessary explicit deps
instead of syncing the version used.
Fixes#2207. This is actually a workaround. Ideally users shouldn't need
to -keep classes, but it's a bit risky to fix the real issue before 1.1.
The further fix will be done as part of #2633.
The interop app's build.gradle change is necessary to compile with newer
Gradle versions. The com.google.errorprone.annotations was necessary in
order to prevent annotation warnings from failing the build.
Garrett Jones
Carl Mastrangelo
Eric Gribkoff
Eric Anderson
Michael Vorburger
ZHANG Dapeng
Ryan Michela
zpencer
Paul Gross
Mehrdad Afshari