Proposal: replace `check` and `apply` with a single task with a CLI flag

[nedtwigg]

Instead of having spotlessCheck and spotlessApply, we could instead just have spotless, which could do the same thing as spotlessCheck. In place of spotlessApply, the user would instead run gradlew spotless --apply.

This might mesh better with the incremental build model being implemented in #31.

[jbduncan]

This may be a problem with IDEs like IntelliJ though, because AFAIK they don't allow one to easily pass command-line arguments upon double-clicking (or otherwise interacting with) a Gradle task on the IDE's UI.

Instead, one has to manually configure command-line options for particular Gradle tasks via a not-easy-to-find-and-use options window (for IntelliJ at least, I don't know about Eclipse or Netbeans), or one would have to use the terminal or command line directly, which for me at least would be a painful to go through, as I'm so used to running Gradle tasks straight from the IDE now. :P

@nedtwigg Could you perhaps explain further why you think this idea might mesh better with the in-progress incremental build model than the current spotless(Check|Apply) split?

[oehme]

The check task should produce an output (a report or similar) and can be up-to-date checked. The apply task modifies its inputs and can thus not be up-to-date checked. Thus the two will have different properties/annotations/implementation. Keeping them separate is the way to go.

In general, passing arguments should be used to slightly modify the behavior of a task, not switch between two fundamentally different things.

[nedtwigg]

Maybe an example will clarify:

gradlew spotlessCheck  // first time takes 90s and passes
<change some files>     
gradlew spotlessCheck  // runs for 1s (because up-to-date checking) then fails
gradlew spotlessApply  // runs for 90s
gradlew spotlessCheck  // runs for 1s and passes

So for every check/apply loop, we don't get much advantage from the up-to-date checking. Why are we doing this in the first place?

Compare that to:

gradlew spotless         // first time takes 90s and passes
<change some files>     
gradlew spotless         // runs for 1s (because up-to-date checking) then fails
gradlew spotless --apply // runs for 1s (because up-to-date checking)
gradlew spotless         // runs for 1s (because up-to-date checking)

Now, for every check/apply loop, we get the full advantage of up-to-date checking.

I think this whole up-to-date thing is crazy :-P, but if we're going to do it, we might as well get some benefit :)

[oehme]

You run spotlessCheck all the time, as part of your usual check task. You only run spotlessApply when you actually want to apply it to your sources.

Apart from that, what you outlined above is not what would happen. If you change an input property (--apply), then the task won't be incremental. So it would take 90s. The benefit with the separate tasks would be that spotlessCheck would remain incremental, so it would only take a short time, even after an apply.

gradlew spotlessCheck  // first time takes 90s and passes
<change some files>     
gradlew spotlessCheck  // runs for 1s (because up-to-date checking) then fails
gradlew spotlessApply  // runs for 90s (only if it's the first time)
gradlew spotlessCheck  // runs for 1s and passes

vs.

gradlew spotless         // first time takes 90s and passes
<change some files>     
gradlew spotless         // runs for 1s (because up-to-date checking) then fails
gradlew spotless --apply // runs for 90s (because a property changed)
gradlew spotless         // runs for 90s (because a property changed)

[jbduncan]

@nedtwigg Ah okay, I think I see.

Please correct me if I've misunderstood something, but in other words, you want spotlessApply to work in such a way that if the previous spotlessCheck fails, then spotlessApply should only format the files that failed the check?

If my understanding is correct, then the first question that comes to my mind is: do we even need these two tasks to be rolled up into one to benefit from this? (Ah, I was ninja'd by @oehme! Apparently rolling up the tasks into one wouldn't work to our benefit anyway.)

Would it not be possible to tell spotlessApply, "Oh hey, if spotlessCheck ran before you did and it failed for whatever reason, please format only the files that spotlessCheck complained about"?

P.S. I personally disagree that the whole up-to-date thing is crazy (I think Gradle and Bazel had the right idea here to support incremental builds), although I do agree it's proving to be quite a lot of work! And I also agree that if we're going to do it, we might as well squeeze out as much performance as we reasonably can. :)

[nedtwigg]

@oehme We can pass --apply without modifying a declared input, so that the incremental build would still work. I'm assuming that when an incremental task fails, it will continue to run on only the "out-of-date" inputs.

[oehme]

@nedtwigg not declaring an input that clearly is one is not something I'd support.

@jbduncan I don't think that's necessary. You'd only pay the price for a full run once. After that spotlessApply would only apply to the changed files. So I don't see a reason to do any hacks with changing inputs at runtime or similar.

[nedtwigg]

Okey doke. We'll keep the current behavior for now. This correctness issue is our real problem. Once we've got everything else solved, I'll come back and look at this with a fresh mind :)

[jbduncan]

@oehme Oh okay, I see. Knowing that we'd only pay the price for a full spotlessApply run once in this case, I'm no longer certain that it's reasonable to ask spotlessApply to play such a hackish dance. :P

Although, having said this, I had a look at the code for ApplyFormatTask again, and I wonder if spotlessApply would just format ALL the files again on its 2nd, 3rd etc runs (rather than just formatting those files that changed), as it currently formats on the target field directly, rather than the out-of-date files obtained from an IncrementalTaskInputs instance.

@oehme @nedtwigg What are your thoughts on me going ahead and changing ApplyFormatTask so it operates on an IncrementalTasksInput rather than formatting target directly?

(I realise the correctness issue is what we really need to sort out right now, so I'd be happy to wait until we're ready to come back to this issue before discussing my question above.)

[nedtwigg]

I'm gonna ixnay IncrementalTaskInputs on ApplyFormatTask and close this issue for now. We'll re-examine when we've got something that works :)

[nedtwigg]

Since the restructure in #56, it's easy to see how little code is really involved in Spotless' gradle hooks. Seems most of it is getter/setter dances :-P. I definitely think it's worth at least tinkering with.

I'm very curious to see perf #'s for a giant repo like one of these:

• https://github.com/jaredjstewart/incubator-geode/blob/spotlessPluginGoogleStyle/build.gradle#L27
• https://github.com/junit-team/junit5/blob/151d52ffab07881de71a8396a9620f18072c65ec/build.gradle#L86-L101

[jbduncan]

When I run Spotless 2.4.0 and 3.0.0-SNAPSHPOT against JUnit 5 SNAPSHOT (./gradlew clean spotlessCheck), I get the following timings.

1. 2.4.0: 6.668 secs
2. 3.0.0-SNAPSHOT: 4 mins 14.837 secs

I'm really curious at to why it's so slow on a clean run now. Is it because steps like EclipseFormatterStep use reflection now?