-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Mon, Oct 5, 2009 at 19:14, Adam Murdoch wrote: > > > 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? > I like the idea of using the road map. I'd suggest making an announcement to the mailing list and on the site. Make sure people are using the vote feature of JIRA. Not really sure what else can really be done. > > Adam > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > - -- Jason Porter Real Programmers think better when playing Adventure or Rogue. PGP key id: 926CCFF5 PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5 PGP key available at: keyserver.net, pgp.mit.edu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.9) iEYEAREIAAYFAkrLX4AACgkQEEbDm5Jsz/ULOgCgq1kik4hFLk4xfFk3aP4Q6Ppr WzEAnRfmdH9Nw7gsN/cZFHL13YQMv0cw =lGqB -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
