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. Should it be the same DSL? Our discussions have proven there are non obvious nuance in this stuff so separate DSLs might make it more understandable. I'd offer some DSL sketches, but I'm on my phone and it's late. > >> >> 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 >
