Adam Murdoch wrote:
Hi,
I'd like to get some feedback on the new task definition DSL I've added
to trunk.
The changes replace the createTask() method with a keyword style syntax
for use in build scripts, and a groovy-ish API for use elsewhere.
The new syntax is:
task <task-name> [(option...)] [ { action } ]
Some examples:
task aTask // was createTask('aTask')
task aTask { do stuff } // was createTask('aTask') { do stuff }
task aTask(type: Copy, dependsOn: someOtherTask) // was
createTask('aTask', type: Copy, dependsOn: someOtherTask)
task aTask(dependsOn: anotherTask) { do stuff } // you can figure this
one out
More examples in the user guide at
http://gradle.org/userguide/latest/tutorial_using_tasks.html
One thing to note is that this syntax works only for statements. It does
not work for expressions. That is, you can't do:
Task someVar = task aTask
For one thing, this isn't actually valid groovy. It would have to look
like:
Task someVar = task(aTask)
which defeats the purpose, I think. It also looks a lot like a call to
the Project.task() method, which is confusing, I think:
Task someVar = task('anExistingTask')
or worse:
taskName = 'anExistingTask'
Task someVar = task(taskName) { configure the task }
For both these reasons, I've limited the syntax to statements.
For defining a task in an expression, or in classes outside the build
script, you can use the API on TaskContainer:
tasks.add(name: 'aTask') // replaces createTask('aTask')
tasks.add(name: 'aTask') { do something }
tasks.add(name: 'aTask', type: Copy)
Finally, Project.createTask() will be deprecated in the 0.6 release, and
removed some time after the release.
Comments?
Although I could certainly live with it either way, I think that in balance, I
liked the previous syntax better.
I don't particularly like having one syntax for use directly in the build file
and a very different one for use programatically.
While trying to get other developers up to speed with Gradle, one of the initial
points of confusion was the difference in the closures used to define the task
action and a closure used for configuration. These seem to have even a more
similar syntax now.
task atask {
// action content
}
atask {
// configuration
}
I found createTask to be a little more descriptive and find the 'task' keyword
too close to the other Project.task methods and Project.getTasks.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
