Fine-grained detection of the classpath would not solve my problem. Here is my usecase:
- Download and extract ~ a gig of data, into folder
- Transform and filter that data into
- Transform and filter that into
- Several other steps, some of which depend on multiple previous steps.
In each case, a standard up-to-date check based on the files takes literally minutes. So, instead I do up-to-date checks based on a single “token” file in the root of the directory, which has the input metadata to the tasks that I expect to change.
Since 3.x, it is entirely impossible to do development on steps 2, 3, 4 in this process, because step 1 will always rerun. Absolutely it is possible to shoot ones’ self in the foot during this process, and we have done so, but dangerous tools are occasionally useful
Before we adopted gradle, these tasks were run by a
public void main(), with clumsy commenting to control which steps to run. With gradle 2.x, we have a great tool for building a task graph with fine control over its execution.
The new default behavior in 3.x (change whenever the classpath changes) is absolutely the right default. But if it’s not possible to override this, then there are some workflows that will have to stick with 2.x indefinitely.