gradle-plugins/toolbox

Allow dependencies on unpublished Gradle API/TestKit

Opened this issue · 1 comments

Sometimes, users may want to test against a specific Gradle release candidate or snapshot. Unfortunately, we don't publish those to Maven Central. Instead, we should generate the JARs locally and consume them as if they were available on Maven Central.

The code already exists under the Gradle API project. We would migrate the code to this repository. There are several ways to integrate the work, but how we do it still needs to be clarified. Ideally, we want to avoid doing the same work multiple times. The ad-hoc repository from the Nokee codebase could be helpful here.

Here are the possible solutions:

  • Embed the JAR generation into the project's configurations and use project dependency.
  • Use ad-hoc repository code from Nokee codebase to generate dependencies on the fly.
  • Use the Maven repository URL provider trick to generate static dependencies.
  • Use generator tasks and self-resolving dependencies.

Solving this issue will allow us to stop maintaining the Gradle API redistribution in favour of generating the JARs on the fly. We may still want to release the API JARs for users not using Gradle, but we would have to figure out if that is worth the effort.

I wrote a POC of what will most likely be released soon in the toolbox plugin. Thanks to the cooperation of two repositories and some clever artifact transforms, we can achieve on-the-fly generation of the Gradle JARs with minimal overhead. The first repository tricks Gradle into thinking that services.gradle.org is a repository (for the distribution). Then, we fix the metadata to add a variant that depends on a generated coordinate (which we generate as needed, thanks to the component metadata rule). Finally, Gradle will locate the correct variant under the generated coordinate. The resolved files are simple markers for the artifact transform to complete the generation and cache the result.

The base idea for the solution is simple, but the implementation needs to work around several bugs (or "features") under Gradle.