Consider migrating Spotless Gradle plugin to use Task Configuration Avoidance

I’m in the middle of migrating my personal project jupiter-collection-testers to use a new feature introduced in Gradle 4.9 called Task Configuration Avoidance, over at this feature branch. However, I am currently stuck on the Spotless Gradle plugin, because even if I don’t run gradlew spotless[Check|Apply], the plugin seems to directly depend on and thus eagerly configure (create) a number of tasks which spotless[Check|Apply] needs but other tasks like help don’t need.

The reason that I believe Spotless is eagerly configuring these tasks, whichever ones they are, is because when I comment out these lines, the command gradlew help -Dorg.gradle.internal.tasks.stats produces the following relatively small output,

1 actionable task: 1 executed
Task counts: Old API 1, New API 58, total 59
Task counts: created 3, avoided 56, %-lazy 95

Task types that were created with the old API
class com.github.benmanes.gradle.versions.updates.DependencyUpdatesTask 1

Task types that were registered with the new API but were created anyways
class org.gradle.configuration.Help 1
class org.gradle.api.tasks.bundling.Jar 1

as opposed to the following larger output,

1 actionable task: 1 executed
Task counts: Old API 12, New API 74, total 86
Task counts: created 75, avoided 11, %-lazy 13

Task types that were created with the old API
class org.gradle.api.DefaultTask 8
class com.diffplug.gradle.spotless.SpotlessTask 3
class com.github.benmanes.gradle.versions.updates.DependencyUpdatesTask 1

Task types that were registered with the new API but were created anyways
class org.gradle.api.tasks.compile.JavaCompile 23
class org.gradle.api.DefaultTask 13
class org.gradle.api.tasks.Delete 9
class org.gradle.language.jvm.tasks.ProcessResources 3
class org.gradle.api.plugins.quality.Pmd 3
class org.gradle.api.tasks.testing.Test 1
class org.gradle.kotlin.dsl.accessors.tasks.PrintAccessors 1
class org.gradle.api.tasks.javadoc.Javadoc 1
class org.gradle.plugins.ide.eclipse.GenerateEclipseJdt 1
class org.gradle.plugins.ide.idea.GenerateIdeaModule 1
class org.gradle.plugins.ide.eclipse.GenerateEclipseClasspath 1
class org.gradle.plugins.ide.eclipse.GenerateEclipseProject 1
class org.gradle.kotlin.dsl.accessors.tasks.UpdateProjectSchema 1
class org.gradle.configuration.Help 1
class org.gradle.plugins.ide.idea.GenerateIdeaWorkspace 1
class org.gradle.api.tasks.bundling.Jar 1
class org.gradle.plugins.ide.idea.GenerateIdeaProject 1

[nedtwigg]

For the benefit of issue subs, this has been released (partially, see #444 for details) in 3.25.0.

[dmoidl]

Hi @nedtwigg,

since this issue already exists, I’m not opening a new one, but I still think that Spotless plugin not playing well with Gradle’s configuration avoidance is an issue.

I recently stumbled upon this when I tried to use configuration avoidance to simplify our build script and realized it’s not working. After some debugging I came to the very same conclusion as OP did - Spotless plugin actually causes some tasks to get configured, while these tasks would not get configured in its absence. This doesn’t seem right to me.

You see, I don’t really care about how Spotless plugin is coded and whether or not it uses the configuration avoidance internally for it’s own stuff, but I do think that it should not mess with other tasks which aren’t associated with spotless in any way. Not only because it’s not necessary, but because some people (such as myself) might actually want to benefit from configuration avoidance in some way and Spotless plugin breaks this.

I didn’t do any in-depth analysis, but just a quick check of the source code, yet I found this part of the code to be the cause of the problem. Obviously, iterating over these tasks makes Gradle configure them even though it normally wouldn’t (using Gradle 5.6, btw.). Knowing that, I came up with a workaround: setting enforceCheck to false on the Spotless extension and manually setting spotlessCheck task as a dependency of Gradle’s built-in check task does the trick.

Since I haven’t yet had the need to study Gradle’s Plugin API, I can’t tell how difficult it would be to fix this. Nevertheless, I think it should be fixed and wanted to bring this up as IMHO, this is not just a performance issue, but an issue in general.