Spotless is breaking configuration avoidance for other tasks

By default, spotless adds the spotlessCheck task as a dependency of the check task. The check task might not exist yet when the spotless task is applied. To allow Spotless to be applied before or after the JavaBasePlugin, we get the check task like this:

https://github.com/diffplug/spotless/blob/def65a1541abd8841d4754278ab45d87537a48f0/plugin-gradle/src/main/java/com/diffplug/gradle/spotless/SpotlessPlugin.java#L114-L116

The problem is that this appears to trigger task configuration for every task in the project.

This is different than Spotless using configuration avoidance itself, this is about Spotless breaking configuration avoidance for other plugins. There has been a long discussion about moving Spotless itself to use configuration avoidance. The end result of that discussion is this unmerged code, which I believe (perhaps mistakenly) will trigger the exact same issue:

https://github.com/carbotaniuman/spotless/blob/93ae599bcbc71848bbd8d48de2ab9532d3fb420b/plugin-gradle/src/main/java/com/diffplug/gradle/spotless/SpotlessTaskSetupConfigAvoidance.java#L92-L96

Configuration avoidance is a performance enhancement. If you adopt the APIs, but don’t test that the build has actually gotten faster / configuration has actually been avoided, then you may or may not be getting any advantage from the work.

If you want to fix this issue, it is easy to experiment right in your buildscript. For example:

spotless {
  enforceCheck = false
}
afterEvaluate {
  tasks.check.dependsOn(tasks.spotlessCheck)
}

This will produce the exact same behavior as enforceCheck = true, but it might fix the configuration avoidance problem. To get a fix merged, it will need to meet the following criteria:

• The fix has been tested and confirmed to actually fix the “eagerly configure other tasks” problem
• Whether the check task is created before or after spotless is applied, Spotless will integrate with it
• (maybe) If no check task exists, Spotless should create one
  • Spotless does not do this right now
  • It probably should though - if you have a folder (e.g. manual) which just has markdown and the only plugin is Spotless, then gradlew check ought to check the formatting of that folder.

Strikethrough is edit by Ned Twigg 9/29: I was wrong about this, Spotless already applies BasePlugin, which creates check. I was confused because the String constant for check is JavaBasePlugin.CHECK_TASK_NAME.

[carbotaniuman]

@nedtwigg I just got back from some other work to focus on the project that inspired this, and I noticed that task configuration avoidance was working properly. Thanks for merging this, I can now rest assured knowing I only have 1 task configured when I run the help command.

For what it’s worth, my unmerged code works correctly, because configureEach() is lazy. 😛

[JLLeitschuh]

@esword That’s quite an impressive performance improvement.