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.
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.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
