On 17/05/2012, at 7:37 AM, Philip Crotwell wrote: > Hi > > Interesting. Would this be a way to reduce the time spent in up to > date checks? It would be a big win if the daemon could flags a task as > needing to be run on a change.
That's a somewhat different thing, but it would use the same capability in the daemon. The 'keep things continuously up-to-date' would be made up of a few pieces: 1. Watching for changes to inputs of the build. There would be 2 types of inputs that we'd watch for changes to: local files, and artefacts in remote repositories. 2. Rebuild the project model as soon as we notice an input to the model has changed. 3. Running the appropriate tasks when one of its inputs has changed. That is, this feature makes heavy use of the up-to-date checks, but doesn't directly make them any better. We could, however, make use of 1) above, to perform some of the work that the up-to-date checks do asynchronously, before the result is needed. In particular, we could: 1. Calculate the hash of a file as soon as we notice it has changed. 2. Calculate the snapshot of a directory as soon as we notice a change in it. 3. Improve the above to be able to make deltas to a directory snapshot. 4. Download an artefact as soon as we notice it has changed (i.e. a new, better, match for a dynamic version, or a changed changing module). 5. Mark a task as out-of-date when we notice one of the above has changed. I'm not so sure this is much of win, given the above - we'd have to spike it and see. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
