On Mon, 2009-07-27 at 15:14 +0200, Hans Dockter wrote: > On Jul 23, 2009, at 9:24 PM, Tomek Kaczanowski wrote: > > > hi, > > > > one of the first Gradle features presented in the user guide, are > > "dynamic tasks" > > (http://www.gradle.org/0.7/docs/userguide/ > > userguide_single.html#N10234). > > My question is, what do you use them for ? Or at least what are > > potential uses of this feature ? > > First off all this example is supposed to demonstrate that you can > apply the dynamic potential of Groovy also for creating the tasks not > just the actions. That might look obvious but for people coming from > the static world of xml scripts that might not be evident. Having said > this, I don't think there are that many use cases. One use case for > example could be, that you might want to write a wrapper for a Maven > build. You could do: > > ['clean', 'compile', 'test', 'package'].each { name -> > tasks.add(name) { > name.execute() > } > }
Unfortunately, this example, and I'm afraid the example of Sections
4.4/4.5 in the user guide, run the risk of trivializing the critical
importance of the ability to programmatically construct tasks.
This feature is what truly separates the new world (Gradle, SCons, Waf,
Gant, Rake, Rant) from the old world (Make, Ant, Maven(*)). Using a
dynamic programming language and an internal DSL allows for
task/target/rule synthesis based on the state of the system -- i.e.
tasks/targets/rules are programmed at run-time according to an
algorithm. This is a huge win over generalization rule processing (à la
Make).
There is no one killer example I'm afraid, but once you have used
task/target/rule synthesis it will just hit you how right it is, and how
wrong all other ways of handling generality are. It happened for me
when I used SCons after using Make and Ant.
(*) Maven is slightly different from all the others in that it has no
way of expressing algorithm in the build configuration files.
> Other dynamic scenarios are better solved with synthetic tasks (i.e.
> task rules)
The single biggest problem here is likely the lack of consistency in the
way some of the terms and jargon get used in all the various build
frameworks.
--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: [email protected]
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:[email protected]
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder
signature.asc
Description: This is a digitally signed message part
