Hi, I started looking into this area this week out of interest. I was surprised about how naive our family of copy tasks are about incremental build, and I'm surprised we aren't being pushed harder to fix this stuff. My guess is that most people get unexpected UP-TO-DATES, curse, run `clean`, then move one.
I have some flights coming up and want to work on a spec for this stuff. Upon thinking about it, I've realised it's not a trivial problem to solve effectively and efficiently. I'm wondering if there are any existing plans or directions for this. Right now, we only consider the source files for up-to-date determination (taking include/exclude into account). This means we effectively evaluate the input source files at least twice: once for up-to-date calculations, and then again for the actual operation. To consider other settings (e.g. includeEmptyDirs, expand(), duplicatesStrategy, rename), a naive implementation would introduce a third evaluation. This is because in terms of comparison, we need associate the configuration options with the files that they act on. If we could persist and compare such an association then we can detect changes. If we had a point in time where we knew that the copy task configuration was no longer going to change, we could do the source file calculation once and cache it. We could add this kind of thing reasonably easily. The task could be informed that it's about to executed and have its inputs queried. At that point we could build up the comparable data structure. At this point I'm just wondering if there were some existing ideas before I put any time into spec'ing that out. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
