Thanks Adam for your insightful comments, my comments below
Please don't think we've dismissed your problem. The discussion so far has
> been about your proposed solution to the problem, ie dependsOn ordering. I'd
> much rather we started with the problem (like your example above), and see
> what solution we end up with (maybe we make incremental build better, rather
> than use dependsOn ordering).
>
> So, I don't think the question is alphabetical ordering vs. dependsOn
> ordering. To me, the question is really about what is missing from the
> dependency model which prevents us from explicitly stating what the actual
> dependency relationships between tasks are. We've discussed this a few times
> on the list already.
>
>
I didn't take it as a dismissal of the problem. I rather like the 5 whys (
http://en.wikipedia.org/wiki/5_Whys) and I've definitely understand gradle
much better after this discussion :)
I will try and analyze what the real dependency hierarchy is for the
integration builds and see if I can port the build logic to conform to that
hierarchy.
I've done so many wonderful things with gradle sofar I wouldn't want to quit
now (really surprised how easy it was to run an embedded tomcat instance for
some webservices, just figuring out now how I can change it into a plugin -
warning: there might be some later questions from me regarding that).
> However, there will always be situations where you need to wire tasks
> together explicitly. The idea is to provide a few low level task graph
> operations and some high level constructs which sit on top of the low level
> stuff.
>
> The low level constructs will be something like:
>
> * Some way to change the dependencies of a task when a given task is
> scheduled to be executed. For example, if the 'ciBuild' task is going to be
> executed in this build, then the 'check' task dependsOn the 'coverageReport'
> task. This might look something like:
>
> ciBuild {
> whenScheduled { check.dependsOn coverageReport }
> }
>
>
I think though that if the above would be available I would have tried to
use that. It sounds a bit in line with what I was thinking at least at that
time.
> * Some way to explicitly schedule a task to be executed when a given task
> is to be executed. For example, if the 'test' task is going to be executed
> in this build, then also schedule the 'testReport' task to be executed. This
> might look like this:
>
> test {
> whenScheduled { gradle.taskGraph.add(testReport); testReport.dependsOn
> test }
> }
>
> * Some way to order task execution without adding dependencies. For
> example, we want to be able to run tests as early as possible, and upload
> tasks as late as possible. This might look like:
>
> test {
> executesBefore tasks.all
> }
>
> upload {
> executesBefore tasks.none
> }
>
> On top of these, we can build a bunch of constructs. For example, it would
> be quite easy to write a custom Task implementation whose dependencies are
> executed in the order they are added.
>
>
>
Thanks again
gretar
