Tomek Kaczanowski wrote:
Hi, one comment - the idea is very nice, but let us not forget that all of this can be achieved using ant,
That might not be true for much longer. The key to these changes is that they provide a declarative approach to defining the contents of a file hierarchy, rather than the imperative approach offered by using Ant tasks.
That is, I can declare in one place the contents of my distribution, and that same declaration can be reused in multiple places: to create a zip, or tar, or exploded dist. Or later a self-extracting exe or a .dmg or an os x app bundle, or whatever. Same with the contents of a war. I can declare it once, and use it to create a war and an exploded war. The jettyRun task can also make use of it, to configure the jetty web context using the declaration of the war contents.
And because the API is declarative, it means Gradle can make use of it. It will be integrated into the incremental builds of Gradle 0.9, so that the archive will be rebuilt only if the set of input files changes. This doesn't work with the Ant tasks. You get false positives when the timestamp of an input file changes but the contents of the file hasn't. And you get false negatives when the set of files change but the timestamps haven't. And this means you almost always do a clean so that you get reliable results. Using the declarative API + incremental builds means you won't have to.
The API will also be integrated into the dependency auto-wiring of Gradle 0.9. Because the API is declarative, Gradle knows what the input files will be, and can figure out where they come from, to add in the appropriate task dependencies. It won't be able to do that for the Ant tasks.
To me, these changes are important. Almost every build customises the archives it builds. Without these changes, these builds won't be able to (easily) make use of some of the key 0.9 features.
so I'd give this task a low priority and concentrate on things that Gradle still lacks.
This is an interesting point. We do lack any real input from the community into prioritisation of the features for a release. We (the Gradle devs) pretty much just choose the things we think are important, but we really are just guessing. What could we do to improve this?
One option is to use the roadmap. Early in the release cycle, we would update the roadmap with what we plan to do, and then invite the community to comment on it.
Thoughts? Adam --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
