John Murph wrote:
I wanna stick my nose in here and say:
On Wed, Aug 26, 2009 at 12:26 AM, Adam Murdoch <[email protected]
<mailto:[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.
I reckon there's something in this. Perhaps gradle -t should only list
the lifecycle tasks by default, and we add a command-line option, say,
gradle -t --all, which lists all the tasks. I think you should still be
able to run any task from the command-line.
Adam
