Gradle: use new lazy tasks API when supported (Gradle 4.9+)

[tbroyer]

See https://docs.gradle.org/current/userguide/task_configuration_avoidance.html

This boils down to:

• using project.tasks.register instead of project.tasks.create
• moving call to project.afterEvaluate and dependsOn outside the configuration closure, and to act on the task (in project.afterEvaluate), use task.configure { … } as task would then actually be a TaskProvider.
• using configureEach instead of all
• using project.tasks.named(…).configure { … } instead of project.tasks[…].…

This can generally be done quite easily with a couple utility functions using version checks.

[uschindler]

Hi thanks for opening this issue! I was looking at this API last weekend and decided to defer that until I released the new version. It's too risky to do this now. I'd like to get the Java 11 compatible version out first, including the fixes for sourceSets and the Gradle plugin portal. The current code had some problems with order of initialization, so this brings another lazy evaluation that needs to be thoroughly tested.

[tbroyer]

Fwiw, 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.html

And 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 moving forbiddenTask.dependsOn(task) outside the closure, to be resolved when forbiddenTask is realized, not the task)

I understand you'd rather do a release before making those changes though.

[uschindler]

The convention mappings were the worst piece of code in Gradle. I am glad that it will be replaced. I did not fully understand how it works yet, but that's just a matter of time.

Do you have a patch of one of your own plugins migrating to new APIs (including if/ten/else to support older versions)? I can look into it next weekend.

[uschindler]

The convention mappings were the worst piece of code in Gradle. I am glad that it will be replaced. I did not fully understand how it works yet, but that's just a matter of time.

Understood it. You change all current task properties to be Property (as final fields). This requires the change of Gradle version (I think we can do this in forbidden v3.0). The same you do in the extension. To have the default values from the extension inherited into the task (unless set explicit in the config), you just use taskProperty.set(/*(Provider)*/ ext.extensionProperty). As Property extends Provider this would wire the task property to the extension with lazy evaluation. If somebody sets the property on the task to a value using taskProperty.set(value), the linkage to the extension is undone and the property has a custom value, no longer inherited from extension.

[tbroyer]

Do you have a patch of one of your own plugins migrating to new APIs (including if/ten/else to support older versions)? I can look into it next weekend.

The simplest is tbroyer/gradle-errorprone-plugin@eb0f35b but only covers configureEach vs. all.
tbroyer/gradle-errorprone-plugin@e795a20 uses Kotlin extension methods;
and finally I have tbroyer/gradle-apt-plugin@5e8b10f and tbroyer/gradle-apt-plugin@432509e that delegate to one of many implementations depending on the Gradle version.
HTH