Specify that `./gradlew spotlessApply` will fix all issues in error message

[veyndan]

When running ./gradlew spotlessCheck, and there's a styling error in several modules, we get an error and a suggested resolution of Run './gradlew :feature:foo:spotlessApply' to fix these violations.

If you are proficient in Gradle, you may correctly deduce that running ./gradlew spotlessApply will fix the violations in all modules. You may also correctly deduce this if you've read the docs.

Otherwise, you will:

1. Run ./gradlew :feature:foo:spotlessApply
2. Rerun ./gradlew spotlessCheck (perhaps because it's part of a git pre-commit hook)
3. Get an error in another module, with the suggested resolution of Run './gradlew :feature:bar:spotlessApply' to fix these violations.
4. Run ./gradlew :feature:bar:spotlessApply
5. Repeat steps 2 to 4 a few times with different modules
6. And eventually rerunning ./gradlew spotlessCheck will pass

As a mobile platform engineer, I've seen these exact steps play out with several people already. Given they are all heeding the advice of the error message already, and other developers outside of our team could be facing the same issue, could it be worth updating the error message to something like the following?

Run './gradlew :feature:foo:spotlessApply' to fix these violations. Alternatively, run './gradlew spotlessApply' to fix all violations.

[nedtwigg]

I've seen these exact steps play out with several people already.

Thanks for sharing this anecdote!

I can't see any reason why we're bothering to specify the exact path. If we just say gradlew spotlessApply that seems better.

Happy to take a PR which makes this change, if anyone has a strong reason why the exact path should stay, chime in.

[jbduncan]

The only reason I can think of to keep the exact path around is to help with very large projects, but I'm not sure how we would detect which subprojects need spotlessApplying, so no strong feelings on the final solution.

[nedtwigg]

The only reason I can think of to keep the exact path around is to help with very large projects

That is a good point, but ideally we would just be so fast and good at up-to-date checking that they don't care. But big slow projects do still exist, but people in those projects are more likely to have the habit of :subproject:task anyway and don't need us to call it out for them. The anecdote is pretty persuasive to me.

[jbduncan]

@nedtwigg That's true, Spotless is pretty darn fast due to its incremental processing and Git ratchet support, so I'm persuaded by this anecdote, too. 👍