On Fri, Apr 12, 2013 at 2:29 PM, Marcin Erdmann <[email protected]>wrote:
> On 11/04/13 21:44, Adam Murdoch wrote: > > > On 12/04/2013, at 3:27 AM, 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! > > > 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. > Ant does not enforce the order of how target dependencies are declared. If a depend relationship between targets conflicts with the depends order, the relationship wins. Hans
