On 11 April 2013 11:27, Marcin Erdmann <[email protected]> wrote:
> On 11/04/13 17:27, Daz DeBoer wrote:
>>
>> In that case, I'm sure a spike of "shouldRunAfter" wouldn't go astray!
>
> Cool. Do I understand correctly that shouldRunAfter is supposed to work
> exactly the same as mustRunAfter with the only difference that if there is a
> cycle then all of shouldRunAfter edges in that cycle should be removed from
> task graph?
I'm sure there's a bit more to it than that. One difference would be
that when parallel processing it should be fine to run the tasks in
parallel. The semantic is more like "shouldStartBefore" in the
parallel case.
I guess to start with we want to look at the use cases we'd like to solve:
- Ant-style soft dependencies A dependsOn("X, Y")
- optimise the order of execution of checks for faster feedback
These may well use slightly different ordering semantics: certainly
the Ant depends ordering requires more sophistication.
>From an older email by Adam:
> The rule should only be applied if the ant target is to be executed. So,
> given ant <target name='A' depends='X,Y'> then:
> * When task 'A' is present in the task graph, then 'X' should run before 'Y'
> * A dependsOn X (as above) and A dependsOn Y
When run in parallel, can X & Y run concurrently? Or perhaps this is a
non-issue, since all ant targets end up executing in the same project,
and will not be parallelised.
--
Darrell (Daz) DeBoer
Principal Engineer, Gradleware
http://www.gradleware.com
Join us 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
