Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dont break config avoidance for other tasks #463

Merged
merged 5 commits into from
Oct 6, 2019

Conversation

nedtwigg
Copy link
Member

@nedtwigg nedtwigg commented Sep 30, 2019

After creating the PR, please add a commit that adds a bullet-point under the -SNAPSHOT section of CHANGES.md, plugin-gradle/CHANGES.md, and plugin-maven/CHANGES.md which includes:

  • a summary of the change
  • either
    • a link to the issue you are resolving (for small changes)
    • a link to the PR you just created (for big changes likely to have discussion)

If your change only affects a build plugin, and not the lib, then you only need to update the CHANGES.md for 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.md for 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 :)

@nedtwigg
Copy link
Member Author

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 -> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there value in doing this in an afterEvaluate?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

project.afterEvaluate(unused -> formatExtension.setupTask(spotlessTask));

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) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's a whenReady that supports an Action now isn't there?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is, but not in Gradle 2.x, which we still support.

@nedtwigg nedtwigg merged commit 2ca2107 into master Oct 6, 2019
@nedtwigg nedtwigg deleted the feature/no-eager-config branch October 6, 2019 05:53
@nedtwigg
Copy link
Member Author

nedtwigg commented Oct 7, 2019

Released in3.25.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants