I have a very large multiproject build that I’m trying to convert to Gradle, and I’m disappointed by the amount of time it takes Gradle to do its up-to-date checks. If I run “gradle --daemon compileJava compileTestJava” twice from the master directory, the second (best possible scenario) build takes 30 seconds to run, and it skips every single task.
On my build machines, I don’t mind - a full blown packaged build takes 20 minutes to run, so a few seconds for an up-to-date check aren’t bad. But, on developer machines, it would be nice to have a slightly less accurate, faster method - perhaps checking the timestamps instead of the MD5s. Since our developers are using an IDE that does its own compilation, it would also be nice to point Gradle to the IDE’s output directory and have it “trust” that the IDE compiled things correctly if the timestamps of the class files are newer than the source files.
I suppose I could implement my own upToDateWhen, but is there anything (existing or planned) that implements this?
While there are some things that we can do to make the actual checks faster, the up-to-date checking also involves dependency resolution, and this is almost always the culprit when the up-to-date checking is slow. You might run with --profile and see how much of the 30 seconds is due to dependency resolution.
Either way, we want to make this faster. Currently, we are working on dependency resolution performance (in particular when everything is cached and up-to-date), which will help bring your build time down. Also, we will probably do an optimisation pass over the checking code too, before 1.0.
Finally, at some point after the Gradle 1.0 release, we will start doing the up-to-date checks and/or the dependency resolution in the background via the daemon, so that everything is ready to go when you run a build.