On 20/07/2011, at 12:53 AM, Hans Dockter wrote: > Build file changes might affect the output of a task. Yet they are not taken > into consideration for the up to date check. At one point we could try to be > really smart about them (e.g. checking the section of the change in the build > file and thus determining which tasks are not up to date). > > For now I would propose the following behaviour: > > - If the build file has changed, rebuild the cache > - Provide some way for a power user to disable rebuilding the cache.
Please, no. I really don't like this idea. We should only run a task if something that affects its outputs change. Not if a build file changes. They're not the same thing. There's 2 main problems with using the build file to invalidate task output: * It's too broad, in that any change to the build file invalidates all the tasks in the build. Picture the poor sucker with a 600 project build trying to tweak his distribution task. Every time he changes, say, the include patterns for the Zip task, he has to wait for a full rebuild to test his changes. * It's not broad enough. There are many places beyond the build script where a task can be defined, or configured. There's parent build scripts, sibling build scripts, applied scripts, plugins, init scripts, buildSrc, plus anything transitively dragged in by these things. In other words, using the build script just doesn't solve the problem. There are 2 types of changes that affect a task's output that we currently don't detect: * The AbstractCopyTask and subtypes do not track changes to the filters and rename rules. * When the classpath for a task changes. I would much rather we fixed these, than invalidate the cache when the build file changes. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
