On 22/03/2013, at 3:09 PM, Luke Daley <[email protected]> wrote:
> > > On 21/03/2013, at 21:02, Adam Murdoch <[email protected]> wrote: > >> >> On 22/03/2013, at 2:49 PM, Luke Daley <[email protected]> wrote: >> >>> >>> On 20/03/2013, at 5:15 PM, Adam Murdoch <[email protected]> wrote: >>> >>>> >>>> On 18/03/2013, at 5:11 PM, Szczepan Faber <[email protected]> >>>> wrote: >>>> >>>>> I'm wondering if there's a better name for the 'mustRunAfter' api method. >>>>> 'mustRunAfter' somewhat communicates that the source task will be >>>>> scheduled automatically if the target task is selected. I realise that >>>>> there might not be anything better. I was thinking about something like >>>>> task.orderingRules.after(someOtherTask) or >>>>> task.orderedAfter(someOtherTask). >>>> >>>> I think we could certainly work on the names of these things. Moving the >>>> task relationships onto a separate namespace is a good idea, but I don't >>>> think 'orderingRules' quite works, because there are several dimensions >>>> beyond ordering. Given an edge from task A to task B: >>>> >>>> * is the relationship mandatory or advisory (must vs should)? >>>> * what are the constraints on A wrt execution of B (must not run if B has >>>> not run, must run if B has run)? >>>> * what are the constraints on A wrt failures of B (run only if B has >>>> completed successfully, run only if B has failed, run regardless of the >>>> result of B)? >>>> * does the presence of A imply the presence B (eg must generate test >>>> report if test task is to be executed)? >>>> * is the relationship implied by the presence of some other task C (eg >>>> when running C then A ${relationship} B)? >>>> >>>> In other words, the namespace needs to work for task dependencies, >>>> finalisers, initialisers, must-run-after constraints, should-run-after >>>> constraints and all the other stuff that affects where and when the task >>>> will be executed. >>>> >>>> A few alternative names: 'executionRules', 'taskRelationships', >>>> 'executionConstraints'. >>> >>> Isn't this all about ordering? That is, influencing the ordering (in some >>> way) of execution of tasks? >> >> It's about both ordering (constraints that specify when a task should or >> must or must not run relative to some other task or tasks) and execution >> (constraints that specify whether a task should or must or must not run >> based on the state of some other task or task). > > Those seem like separate things, where the latter implies something in terms > of the former. Quite possibly. An execution constraint on the state of some other task means that we have to defer execution of the task until we know the state of the other task, which we could treat as an ordering constraint. There are other types of execution constraints, though, that don't imply an ordering, such as I can't run task A and task B at the same time. The problem I have is that these are, to me, just facets of a single thing, namely the task relationship, and I'd like a DSL that defines things in terms of the task relationships, not the relationships decomposed into a bunch of constraints. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
