On 11/04/13 21:44, Adam Murdoch wrote:
On 12/04/2013, at 3:27 AM, Marcin Erdmann <[email protected]
<mailto:[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!
I'd like us to choose a real use case and use that to drive these task
execution features, similar to using the reporting to drive the
finalisers. Some options:
- Fixing Ant import: given <target name="a" depends="b,c"> then c
should run after b when a is in the task graph.
- Introduce build types: given build type 'a' runs 'b' and 'c' then c
must run after b when a is in the task graph.
- Faster feedback: run faster verification tasks before slower
verification tasks, and verification tasks before other tasks. Workers
can ignore this ordering when in parallel mode if it means that they
would otherwise stall.
- Run validations early in the build: for example, validate my
repository credentials before doing anything else.
- Allow project output to be used at configuration time by other
projects: for example, I have a project 'a' that publishes a Gradle
plugin and a project 'b' that uses it. When project 'b' is to be
configured, then the tasks that build the plugin should be scheduled
and executed and then configuration proceeds.
- Automatically set up and tear down resources used by tests: given my
tests need my web app to be deployed, then start the web container and
deploy the app only if my tests need to run (e.g. are not up-to-date),
and stop the web container immediately after the tests have completed.
Interested in any of these?
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?
It depends. If the constraint is there for Ant compatibility, then
that's true. If the constraint is there for faster feedback, then it
can additionally be ignored by parallel workers.
I understand that the list of features is probably ordered by how
important they are for you but I would like to pick the last one which
would allow me to finish finaliser tasks. You probably recall one of my
previous emails where I said that I used mustRunAfter to enforce running
finaliser tasks as soon as possible which might lead to some cycles in
tasks ordering. We could use changing that to shouldRunAfter as the
driver for that ordering.
Can you please explain why Ant compatibility would use shouldRunAfter
instead of mustRunAfter? It feels to me like if you want it to behave
like if Ant was used it should fail if the order that Ant would use
cannot be achieved. That would allow us to always ignore shouldRunAfter
ordering in parallel mode.
