On 31/01/2013, at 12:56 AM, Hans Dockter wrote: > <snip> > > 1. Build the task graph proper, with a node for each task in the graph and > edges to represent the various types of dependencies. > > Which is then also something we can expose. It contains valuable information > to a build master which is at the moment not available in any form. So this > is a great feature by itself.
Absolutely. It also offers a place where you can mess with the graph before we start executing it, so that if our high level DSL doesn't describe what you need, then you can add the nodes and edges you need yourself. We might offer a way to remove things, too. I see it as being very similar to the module dependency resolution: we have a bunch of domain objects and other declarative things that we transform into a normalised graph of the constraints, and an algorithm that resolves them. We can allow you to write rules that mess with the transformations. For example, we might let you substitute one task for another using a rule. Or override the dependencies of a task just prior to adding it to the graph. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
