I wanna stick my nose in here and say:
On Wed, Aug 26, 2009 at 12:26 AM, Adam Murdoch <[email protected]> wrote:
>
> - Declare the inter-project dependencies by attaching project artifact
> dependencies to configurations, and let these drive the worker task
> dependencies. There's no reason why can't allow something like this as a
> replacement for dependsOnChildren():
>
> dependencies {
> distribution subprojects { configuration = 'runtime' )
> }
>
+1
I generally don't dependsOnChildren() because I find myself always
explaining it as "makes tasks in this project depend on tasks with the same
name in subprojects. Kinda weird, I know." That last part always makes me
think I would rather the behavior be more explicit. I think Adam's idea is
more explicit without being much more verbose (because I will usually
already have a dependencies closure).
>
> - Add lifecycle tasks as a layer above the worker task. We would add pretty
> much the same lifecycle tasks, such as build, buildDependents, buildNeeded,
> etc.
>
I still wonder if lifecycle tasks and worker tasks should both be tasks...
seems like that concept is now doing two different things. As a general
rule, I only wish to run lifecycle tasks. Lifecycle tasks should be
composed from worker tasks. That makes me think worker tasks should be more
like private methods and lifecycle tasks should be more like public
methods. I'm not sure I have a real proposal here, just an observation.
--
John Murph
Automated Logic Research Team
