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

Move to latest Gradle API and best practices #323

Open
jjohannes opened this issue May 20, 2022 · 5 comments
Open

Move to latest Gradle API and best practices #323

jjohannes opened this issue May 20, 2022 · 5 comments

Comments

@jjohannes
Copy link

This is not a request but a proposal. @int128 if you would like to see this done, I will provide a PR with the changes. But since this is a larger change, I want to ask first.

Describe the feature

We are using this plugin in a project with Kotlin DSL and noticed that the plugin lacks behind in some of the latest Gradle features we would like to consistently use in our project:

  • Lazy configuration types for task inputs/outputs (e.g. DirectoryProvider instead of File)
  • TaskProvider<MyTask> instead of MyTask in API/DSL for task configuration avoidance
  • No Groovy specific types in public API (like Closure) to be Kotlin DSL friendly
  • @CompileStatic for Groovy code to be more performant at configuration times.

Why do you want the feature?

We would like to consistently use the features listed above in out build together with this plugin.

Notes:

  • If I do the change, I would attempt to not change the existing DSL for Groovy. E.g., even if we change from File to DirectoryProperty, you can still assign a File. You just also can assign lazy typed values - Provider<Directory> - as well.
  • Still, these will be 'API changes' and you might want to increase the major version of the plugin with this change.

Let me know if there are any concerns. If you would like to see this contributed, I would give it a try in a few days.

@simondivi
Copy link

@int128 ping?

@sreich
Copy link

sreich commented Mar 15, 2023

bump on this? @int128 @jjohannes interested. especially wiht gradle 8.0 and whatever potentials are to be had by that

@jjohannes
Copy link
Author

I am still interested in contributing this.

@roseaneesha
Copy link

I am interested in contributing

@jjohannes
Copy link
Author

I have started some work in #409 to make the plugin configuration cache compatible, which is the minimum we need to continue using it.

I would use that as the base to resolve this issue. It already moves a few things to "current best practices".

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

4 participants