On 10/01/2011, at 2:05 PM, Hendy Irawan wrote:
> Thank you Adam.
>
> Forgive me to bring this simple question into a discussion.
>
> I beg to disagree. How can it not be a task? Who decides? Me or
> Gradle?
A bit of both. Gradle decides what the terms 'task' and 'action' mean, for the
purposes of writing build logic. You, the author of the build logic, get to
decide if a given piece of code is to be used as a task or as an action. At the
moment, however, you as the user of the build logic cannot decide - it's baked
into its definition. A piece of code can only be used as a task if it extends
DefaultTask. But then, it cannot be used as anything other than a task.
This is something we want to change. It should be possible to write a piece of
build logic which can be used as either a task or an action, at the user's
discretion, not the author's.
For example, you might be able to use a POGO type as a task type. So, in your
example, you might have something like:
class SshCommand {
String username
String password
@Action
def execute() { .... }
}
// Use the type to define a task
task ssh(type: SshCommand) {
username = '...'
}
// Use the task as an action
task ssh << {
def ssh = new SshCommand()
ssh.username = '..'
ssh.execute()
}
We might even get rid of Task types altogether, so that you only provide an
action type when you declare a task. This is appealing for a few reasons:
* Custom build logic is inherently more reusable in other contexts
* We can remove DefaultTask from the public API. This is really an internal
implementation detail
* We can get rid of the duplication in Exec/JavaExec/Copy/Delete etc (see
below).
>
> Actually it is similar to Exec(Task) and project.exec are used. Exec
> can be used either way. Why can't our own tasks be like that?
Not quite. The Exec task and the exec() method both share a common ExecAction
implementation. If we made the changes above, then we wouldn't need this
duplication. And it would also work for custom logic.
>
> Since Exec is the role model in this regard, I've tried to look at
> project.exec's implementation. I was expecting a simple wrapper of
> Exec task, but it's not. It actually has several redirections and in
> the end I'm not sure if it actually uses Exec task at all.
It's the other way around. The Exec task uses the Exec action.
>
> I thought the purpose of custom tasks is to make them reusable?
Indeed. And they are, but only as tasks. Again, this is something we want to
change, so that the logic is reusable in more contexts.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
