Update test proto to match stubby4 test server / grpc-proto repo.
- Deprecated PayloadType since it only provide 1 option.
- Change test cases to ignore deprecated field in Payload
Only the dummy-default version should ever be promoted. Test versions
should have no traffic routed to it, so that deletions are
simpler. Versions receiving traffic can not be deleted in GAE.
This PR adds an automatic gradle format checker and reformats all the *.gradle files. After this, new changes to *.gradle files will fail to build if not in good format, just like checkStyle failure.
The new jmh plugin fixes a warning for the newer version of Gradle.
The new AppEngine plugin still produces a warning, but updating it
anyway so people know that upgrading the plugin doesn't fix the problem.
The new android-maven plugin fixes a build problem with the newer
Gradle.
The Visual Studio fixes were necessary starting ~4.4.
https://github.com/gradle/gradle-native/issues/34#issuecomment-335222096
describes the change in behavior.
There's nothing immediately being used as part of this update. It's just
to keep us current and to get us over that Visual Studio change hump.
OkHttpClientInteropServlet and NettyClientInteropServlet both run the
@After method from AbstractInteropTest. Let's make sure we await
termination.
For the long lived channel test, do the cleanup in `destroy`.
By doing this we can isolate the Census records for each test, and
eliminate the trial-and-error workaround in AbstractInteropTest.
This is a preferred fix for #3777 and supersedes #3803
While using + is convenient, it prevents builds from being
deterministic which makes it hard/impossible to reproduce a historic
build or execution results.
Turns out the ManagedChannelBuilder was misbehaving because the
devserver launcher ignores the app's jdk7 configuration and uses
whatever jdk is in JAVA_HOME. This is the reason
GrpcUtil.IS_RESTRICTED_APPENGINE was wrong.
Changing JAVA_HOME to point to jdk7 reveals that devservers lack
conscrypt. Adding an explicit check to make sure the jdk7 test is not
running in a dev server.
Since the projects are placed in the root settings.gradle, they are subprojects
and don't need their own gradlew. In addition, the gradle version used here is
a different version than elsewhere, which is asking for confusion.
Jihun Cho
Eric Anderson
Spencer Fang
ZHANG Dapeng
Carl Mastrangelo
Kun Zhang