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). > > The higher level primitives (e.g. containers) don't fit into this mental > model, but I don't think that's a problem. Right. The higher level stuff would live elsewhere, as it already does for things like project dependencies and so on. > This is a more concrete construct. > >>> Cheers! >>> >>> On Mon, Mar 18, 2013 at 12:59 AM, Adam Murdoch >>> <[email protected]> wrote: >>> >>> On 18/03/2013, at 7:33 AM, Marcin Erdmann <[email protected]> wrote: >>> >>>> As the code has now made it into master shouldn't this issue be marked as >>>> resolved? >>> >>> Not quite yet, as there are a few other use cases bundled up in that issue. >>> I guess the right thing to do would be to add new issues for the use cases >>> we haven't fixed yet and close the issue. >>> >>>> >>>> On 07/03/13 09:29, Taytay wrote: >>>>> As someone who has been following this bug >>>>> <http://issues.gradle.org/browse/GRADLE-427> closely for a while, let me >>>>> take a moment to thank you for the work you've done here erdi! >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://gradle.1045684.n5.nabble.com/Must-run-after-ordering-tp5710924p5710986.html >>>>> Sent from the gradle-dev mailing list archive at Nabble.com. >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe from this list, please visit: >>>>> >>>>> http://xircles.codehaus.org/manage_email >>>>> >>>>> >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this list, please visit: >>>> >>>> http://xircles.codehaus.org/manage_email >>>> >>>> >>> >>> >>> -- >>> 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 >>> >>> >>> >>> >>> -- >>> Szczepan Faber >>> Principal engineer@gradleware; Lead@mockito >>> Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: >>> http://www.gradlesummit.com >> >> >> -- >> 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 >> > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: > http://www.gradlesummit.com > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- 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
