I’m aware that Gradle very carefully examines dependencies, so that tasks are only rerun if their dependencies are out of date. This is an advantage. However, there are times when I wish it was just a little smarter.
It seems reasonable to me that if the build script itself changes, all tasks should be rerun. I know about the “–rerun-tasks” command-line parameter, but it would make more sense if this would happen automatically.
I’m not aware of any way to configure this in the build script itself, and I wouldn’t want to do that if it required hardcoding the name of the script itself.
The Gradle up-to-date checking is much more granular than that. Quite simply, it does not rerun a task if it’s input/outputs haven’t changed. If you changed your build script in such a way as to modify a tasks’s input/outputs then it will indeed rerun. The idea is to avoid reexecuting the entire build in response to a trivial build script change that doesn’t actually effect task outputs.
If you are indeed making changes that should effect task output but isn’t triggering the task to run again it might be an indication that the task isn’t configured correctly, or isn’t properly declaring all its inputs/outputs.
So, for instance, should the “ear” task be rerun if the “ear” block (what is the best convention for the name of this entity? Is “block” reasonable? Just trying to communicate better.) in the build script changes, I would think the “ear” task should rerun in that case. It doesn’t, in my experience.
It will rerun if Gradle determines that the change will affect the output of the task. In essence, the input to the ‘ear’ task is a ‘CopySpec’. For example, if I tell the ‘ear’ task to include files from an empty folder, this addition will not change the output, so no need to rerun. If you are in fact making a change that should affect the output (ie. doing a clean the running the task again produced a different output) then that might indicate a problem.
Ok. I verified an example of that. I thought I had seen a case where I made a script change and reran, and it didn’t redo the task in question. I’ll have to watch for that again.
This is GRADLE-2936.
We are preparing for tackling this and I expect we’ll make progress in 2.4 or 2.5.