On 14/06/2012, at 11:03 PM, Luke Daley wrote:
> Howdy,
>
> On a project I am working on, I'm orchestrating a release process. Part of
> this is checking out the project from a tag and running a build against the
> checkout. It's awkward to use a task in this case as it's one step in a
> sequential workflow. I can make a GradleBuild task work, but it is awkward.
>
> Is there any good reason not to offer a gradleBuild {} “imperative” method
> like javaexec {}, copy {} etc.? I think it makes sense to offer it.
>
>
> Speaking more generally, I'm seeing this kind of issue more and more. It can
> be inconvenient to lock functionality up behind the task mechanism. I think
> the core issue here is that tasks don't really compose into larger “atomic”
> pieces.
So we should fix this, rather than work around it.
>
> I think as a general philosophy and approach, we should be careful about
> locking functionality up behind tasks. Tasks should just adapt the
> functionality into our execution mechanism. This leads to some duplication,
> but it makes the most sense to me. We already do this sometimes, but I
> wouldn't consider it a consistent approach. What are others thoughts on this?
> I've been saying this kind of thing to plugin developers etc. and in
> trainings for a while.
>
> Longer term, a richer execution model will alleviate some of this stuff but
> I'm not suggesting pursuing this now.
Don't assume this stuff is longer term. We should add the stuff we need rather
than work around it with imperative stuff. It's not one big bang feature - it's
a bunch of smaller ones.
The plan is to use declarative tasks and not imperative actions for all work
that Gradle does, and push this more and more. Actions do not scale. Tasks do.
Having said that, there are 2 things we might do to bridge the task and action
world:
* Support pojo task types, combined with dependency injection. This way, you
don't need to implement Task, and we'll take care of filling in the missing
pieces when we happen to need a Task instance.
* Allow arbitrary Runnable instances to be instantiated from such pogo types.
This way, there is no difference between an action implementation and a task
implementation - they're the same thing. It's how the instances are used that
determines whether the logic is an action or a task.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
