Gradle: use new lazy tasks API when supported (Gradle 4.9+)
See original GitHub issueSee https://docs.gradle.org/current/userguide/task_configuration_avoidance.html
This boils down to:
- using
project.tasks.register
instead ofproject.tasks.create
- moving call to
project.afterEvaluate
anddependsOn
outside the configuration closure, and to act on the task (inproject.afterEvaluate
), usetask.configure { … }
astask
would then actually be aTaskProvider
. - using
configureEach
instead ofall
- using
project.tasks.named(…).configure { … }
instead ofproject.tasks[…].…
This can generally be done quite easily with a couple utility functions using version checks.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Gradle 4.9-rc-1 Release Notes
The Gradle team is pleased to announce Gradle 4.9. First and foremost, this version of Gradle features experimental new lazy task API.
Read more >Kotlin Gradle Plugin: Use new Gradle API for Lazy tasks
This API allows minimizing amount of tasks created on each build or task invocation. It's especially important for big multimodule projects because each...
Read more >Butterknife plugin doesn't use lazy task APIs of gradle 4.9+
Butterknife doesn't use the new APIs and trigger the creation of most of tasks for most variants. I believe the only thing to...
Read more >Upgrading your build from Gradle 4.x to 5.0 - API Manual
Maven 3 only supports unique snapshots, so we decided to remove them. Tasks & properties. The following legacy classes and methods related to...
Read more >Grolifant : A Library to Support Gradle Plugin Development
ysb33r.grolifant.api . The reason for this is that in future the package will be used to indicate a level compatibility. For instance if...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
The simplest is https://github.com/tbroyer/gradle-errorprone-plugin/commit/eb0f35b32b81a8f9d28f4b1aa790bac4b371b704 but only covers
configureEach
vs.all
. https://github.com/tbroyer/gradle-errorprone-javacplugin-plugin/commit/e795a20cc1ef77f35ef3baf7c8d509f5546f3310 uses Kotlin extension methods; and finally I have https://github.com/tbroyer/gradle-apt-plugin/commit/5e8b10f76d13584ed54f183c771fbd10ec3036a0 and https://github.com/tbroyer/gradle-apt-plugin/commit/432509ec85d1ab49296d4f9b21fad876523c6a8a that delegate to one of many implementations depending on the Gradle version. HTHFwiw, the plugin could also use lazy configuration instead of
conventionMapping
, though that would mean bumping the minimum supported Gradle version to 4.3 (or maybe even 4.4). See https://docs.gradle.org/current/userguide/lazy_configuration.htmlAnd wrt the lazy tasks API, I haven’t had any issue moving to that in my own plugins and builds; you of course have to be cautious and only do in the configure closures what cannot be done with a
TaskProvider
(hence movingforbiddenTask.dependsOn(task)
outside the closure, to be resolved whenforbiddenTask
is realized, not thetask
)I understand you’d rather do a release before making those changes though.