On that note; I have another cases which would benefit greatly from incremental approaches;
I create an aggregated Jar file, by first unzipping many Jars to file, followed by jarring those into a single new Jar. If the unzip don't do anything if the target files are newer than the source jar, and likewise that only files newer than destination jar are *added* to the destination Jar, it would save me a lot of time. Files that are 'no longer' on file system is not required to be handled, but if so, use last modified date on the containing directories against the Jar instead of looking inside and see what is missing (that is still slow on large jars). Cheers Niclas On Sat, Jun 25, 2011 at 5:13 PM, Hans Dockter <[email protected]> wrote: > I think it would be worthwhile to tackle an incremental copy task. What I > mean by that is to make the Copy task smart enough to copy only those files > that have changed. The generic incremental build will figure out whether > anything has changed. If at least one input/output file has changed the copy > task is triggered and then copies _everything_ again. It would be nice if > the incremental build API could be used by the Copy task to query which > files have changed and only copy those. It has this information. That would > be a nice and simple use case for hammering out a public API for querying > the incremental build. > Hans > -- > Hans Dockter > Founder, Gradle > http://www.gradle.org, http://twitter.com/gradleware > CEO, Gradleware - Gradle Training, Support, Consulting > http://www.gradleware.com > Please vote Gradle for JAX Awards: http://vote.jax-awards.com > > > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
