On 12/04/2013, at 10:29 PM, Marcin Erdmann <marcin.erdm...@proxerd.pl> wrote:
> On 11/04/13 21:44, Adam Murdoch wrote: >> >> On 12/04/2013, at 3:27 AM, Marcin Erdmann <marcin.erdm...@proxerd.pl> 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. They were (more or less) ordered from least effort to most effort. Or perhaps more accurately, by how much other stuff is missing beyond task execution stuff. Regardless, they're all things I would love to see implemented. I'm sure we can chop up the last one into some smaller pieces that focus on the task execution but still help with solving the use cases. -- 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
