I kinda like the 'soft dependency' term (whatever exactly it would be). It has a baggage, at least for me. I always considered ant ordering hints as 'soft dependencies'.
If we need a general term for all those kinds of rules (and I'm not sure we need it, maybe we should not have it) I would think about "task dependency rules". Let's get this discussion distilled into a spec soon. We're talking about terrific features here. Cheers! On Wed, Jan 30, 2013 at 11:56 PM, Adam Murdoch <[email protected]> wrote: > > 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 > -- Szczepan Faber Principal engineer@gradleware Lead@mockito --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
