google-nomulus/gradle
jianglai 6352b8a01a Use self-managed credential in remote api installer
RemoteApiOption has a package-private method that takes a Stream representing the content of a JSON and use a GoogleCredential created from it as its credential. This CL uses reflection to change the access modifier of that method in order to supply a credential stream that is self-managed. This is obviously not ideal and prone to breakage in case the getGoogleCredentialStream method is changed. Unfortunately upstream is not willing to make it public citing the reason that GoogleCredential.fromStream() (which getGoogleCredentialStream uses) is a @Beta annotated function (see https://groups.google.com[]forum/#!searchin/domain-registry-eng/remoteapioptions%7Csort:date/domain-registry-eng/Flsah6skszQ/CySZv2XEBwAJ). However this function is introduced 5 years ago as a public function (b857184bfa). I think at this point it is safe to assume that it is part of the widely used APIs and will not change without sufficient notice.

Note here that RemoteApiOptions creates its own copy of GoogleCredential to be used to call App Engine APIs locally, whereas communications to Nomulus endpoints use the Credential provided in AuthModule. Even though both credentials are created from the same client id, client secret and refresh token (the three elements needed to construct a GoogleCredential this way, see https://github.com/googleapis/google-api-java-client/blob/master/google-api-client/src/main/java/com/google/api/client/googleapis/auth/oauth2/GoogleCredential.java#L842), their refreshes cycles are independent of each other. I verified that refreshing one of the credential does not invalidate the access token of the other credential, as long as it is not expired yet.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=224156131
2018-12-05 16:02:28 -05:00
..
backend Add App Engine Deploy to Gradle build 2018-12-03 19:18:44 -05:00
core Use self-managed credential in remote api installer 2018-12-05 16:02:28 -05:00
default Add App Engine Deploy to Gradle build 2018-12-03 19:18:44 -05:00
gradle/wrapper Check gradle wrapper in to VCS 2018-12-03 19:26:38 -05:00
proxy Create proxy Docker image with Gradle 2018-11-19 18:19:27 -05:00
pubapi Add App Engine Deploy to Gradle build 2018-12-03 19:18:44 -05:00
third_party Reorganize Gradle dependencies 2018-10-25 14:50:26 -04:00
tools Add App Engine Deploy to Gradle build 2018-12-03 19:18:44 -05:00
util Create proxy Docker image with Gradle 2018-11-19 18:19:27 -05:00
build.gradle Add App Engine Deploy to Gradle build 2018-12-03 19:18:44 -05:00
gradlew Check gradle wrapper in to VCS 2018-12-03 19:26:38 -05:00
gradlew.bat Check gradle wrapper in to VCS 2018-12-03 19:26:38 -05:00
README.md Define multiple test suites under Gradle for better test performance 2018-11-16 16:55:55 -05:00
settings.gradle Add App Engine Deploy to Gradle build 2018-12-03 19:18:44 -05:00

This folder contains experimental Gradle scripts as an alternative to Bazel for the open-source Nomulus project. These are work-in-progress and are expected to evolve in the near future.

All testing is done with Gradle v4.10.2.

Current status

Currently there are two sub-projects, third_party, which contains the back-ported JUnit 4.13 code; and core, which contains all Nomulus source code. Gradle can be used to compile and run all Java tests.

Gradle is configured to use the directory containing this file as root, but use the existing Nomulus source tree.

Dependencies are mostly the same as in Bazel, with a few exceptions:

  • com.googlecode.java-diff-utils:diffutils is not included. Bazel needs it for Truth's equality check, but Gradle works fine without it.
  • jaxb 2.2.11 is used instead of 2.3 in Bazel, since the latter breaks the ant.xjc task. The problem is reportedly fixed in jaxb 2.4.
  • The other dependencies are copied from Nomulus' repository.bzl config.
    • We still need to verify if there are unused dependencies.
    • Many dependencies are behind their latest versions.

Notable Issues

Test suites (RdeTestSuite and TmchTestSuite) are ignored to avoid duplicate execution of tests. Neither suite performs any shared test setup routine, so it is easier to exclude the suite classes than individual test classes. This is the reason why all test tasks in the :core project contain the exclude pattern '"/TestCase.", "/TestSuite."'

Many Nomulus tests are not hermetic: they modify global state (e.g., the shared local instance of Datastore) but do not clean up on completion. This becomes a problem with Gradle. In the beginning we forced Gradle to run every test class in a new process, and incurred heavy overheads. Since then, we have fixed some tests, and manged to divide all tests into three suites that do not have intra-suite conflicts. We will revisit the remaining tests soon.

Note that it is unclear if all conflicting tests have been identified. More may be exposed if test execution order changes, e.g., when new tests are added or execution parallelism level changes.

Initial Setup

Install Gradle on your local host, then run the following commands from this directory:

# One-time command to add gradle wrapper:
gradle wrapper

# Start the build:
./gradlew build

From now on, use './gradlew build' or './gradlew test' to build and test your changes.

To upgrade to a new Gradle version for this project, use:

gradle wrapper --gradle-version version-number