Gradle plugin in master to depend on the Linkage Checker master

まず scripts/prepare_release.sh、build.gradle、およびリンクされている RELEASING.md ファイルを読んで、現在のバージョニングとリリースの流れを理解します。Gradle プラグインが dependencies モジュールをどのように利用しているかを比較し、proposal に記載されたリリース動作を定義します。master が LinkageChecker master を使用でき、リリースでは両方のコンポーネントを同じバージョンに固定し、Gradle 固有のタグサフィックスが不要になれば完了です。

As of now, a change to the LinkageChecker class is not immediately used in the Gradle plugin, because the Gradle plugin uses a fixed version of the "com.google.cloud.tools:dependencies" artifact. This disconnection causes pain in:

• the increased release procedure for the Gradle plugin
• the late validation of a LinkageChecker's change against the Gradle plugin

Current Release Procedure

Everytime we change LinkageChecker in the dependencies module, we need to do the following

• release the dependencies module as part of https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/RELEASING.md
• wait until the latest version of the dependencies module appear in Maven Central
• update Gradle plugin to use the latest version (example pull request)
  • This may involve code change in the Gradle plugin. This change could happen before the dependencies module if the Gradle plugin in master branch relies on the LinkageChecker in master.
  • If this upgrade reveals a LinkageChecker's bug for Gradle plugin, we have to go back to the change that caused the bug.
• release the Gradle plugin https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/gradle-plugin/RELEASING.md (example pull request)
  This uses vX.Y.Z-gradle release tag. This version is independent from the Maven enforcer rule's version.

Proposal

The Enforcer Rule in Maven and the Gradle plugin in Gradle

This is an enhancement of current setup of mixing Gradle and Maven and this proposes to enhance the release script "scripts/prepare_release.sh" so that:

• the Gradle plugin in master branch relies on the LinkageChecker in master. (version latest.integration)
• When the release script creates a release tag, it sets the dependencies module version in build.gradle to the releasing version. Suppose we use v1.6.0-dependencies.
• We release the Linkage Checker enforcer rule and the Gradle plugin using the tag v1.6.0-dependencies. No need to wait for Maven Central. As the result, the enforcer rule and the Gradle plugin will have the same version for one release.
  (We no longer use the vX.Y.Z-gradle release tag suffix.)

The Gradle plugin to have java.sourceSet to include ../dependencies/src/main/java

This would have duplicate

Other options considered

Everything in Maven

https://stackoverflow.com/questions/27555560/how-can-i-build-a-gradle-plugin-with-maven . Spring Boot's Gradle plugin was developed in Maven. But now they develop it in Gradle.

The stackoverflow explains https://repo.gradle.org/gradle/libs-releases-local but the latest of https://repo.gradle.org/gradle/libs-releases-local/org/gradle/gradle-core-api/ is 6.1.1. (The latest Gradle version is 6.6). Yet, if some artifacts are missing in Maven Central but available somewhere (as part of Gradle distribution), we can create a Maven local ("libs" directory) repository that holds the artifact in this cloud-opensource-java repository just to build our Gradle plugin. Alternative to the lib directory, we can use the maven-install-plugin to move them to he local repository.

If we don't use Gradle's "com.gradle.plugin-publish" plugin, we'll need to figure out how to upload artifacts to Gradle's plugin repository. (If the Gradle repository changes how it works, we're responsible to adjust it.)

Everything in Gradle

Jib project is all Gradle. They develop Jib Maven plugin in Gradle.

We have settings done in Maven:

• The Maven invoker plugin for the enforcer rule integration tests.
• The release script uses mvn versions:set to apply changes to pom.xml at once.

It's feasible but this effort does not sound good just for this purpose to align the Gradle enforcer rule and Maven enfrocer rule.