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'.
>
> 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
