Dont break config avoidance for other tasks #463
Conversation
…valuate`, for easier management by other scripts.
…configuring other tasks.
|
Fixes #444. |
…at we can avoid `getTasks().withType(SpotlessTask.class`. Allegedly `withType` triggers task configuration, although our test indicates that it doesn't at least in 4.9. Better to use the recommended API regardless, especially since we can do so without breaking 2.x support.
|
|
||
| // after the project has been evaluated, configure the check and format tasks per source set | ||
| project.afterEvaluate(this::createTasks); | ||
| project.afterEvaluate(unused -> { |
There was a problem hiding this comment.
Is there value in doing this in an afterEvaluate?
There was a problem hiding this comment.
I think so. People can have multiple spotless blocks (such as a default one in a subprojects block in the the root project, then making little changes in a specific subproject), so we have to wait until the script has finished running to know if enforceCheck is true or not. It's the same reason we do afterEvaluate here:
We used to do all the config in afterEvaluate, the main change in the first commit is to create the unconfigured tasks immediately, because it makes it easier for users to connect them with other tasks to not have to do those connections in an afterEvaluate block.
| checkTask.dependsOn(spotlessTask); | ||
| applyTask.dependsOn(spotlessTask); | ||
| // when the task graph is ready, we'll configure the spotlessTask appropriately | ||
| project.getGradle().getTaskGraph().whenReady(new Closure(null) { |
There was a problem hiding this comment.
I think there's a whenReady that supports an Action now isn't there?
There was a problem hiding this comment.
There is, but not in Gradle 2.x, which we still support.
|
Released in |
After creating the PR, please add a commit that adds a bullet-point under the
-SNAPSHOTsection of CHANGES.md, plugin-gradle/CHANGES.md, and plugin-maven/CHANGES.md which includes:If your change only affects a build plugin, and not the lib, then you only need to update the
CHANGES.mdfor that plugin.If your change affects lib in an end-user-visible way (fixing a bug, updating a version) then you need to update
CHANGES.mdfor both the lib and the build plugins. Users of a build plugin shouldn't have to refer to lib to see changes that affect them.This makes it easier for the maintainers to quickly release your changes :)