Gradle plugin in master to depend on the Linkage Checker master

Commencez par lire scripts/prepare_release.sh, build.gradle et les fichiers RELEASING.md liés afin de comprendre le processus actuel de versioning et de release. Comparez la manière dont le plugin Gradle consomme le module dependencies et définissez le comportement de release décrit dans la proposition. Le travail est terminé lorsque master peut utiliser le LinkageChecker master, tandis que les releases verrouillent les deux composants sur la même version et n’ont plus besoin du suffixe de tag spécifique à 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.