Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow dependencies on unpublished Gradle API/TestKit #93

Open
lacasseio opened this issue Aug 25, 2023 · 1 comment
Open

Allow dependencies on unpublished Gradle API/TestKit #93

lacasseio opened this issue Aug 25, 2023 · 1 comment
Assignees

Comments

@lacasseio
Copy link
Member

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.
@lacasseio
Copy link
Member Author

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.

@lacasseio lacasseio self-assigned this Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant