On 12/04/2013, at 10:51 PM, Hans Dockter <hans.dock...@gradleware.com> wrote:
> > > On Thu, Apr 11, 2013 at 10:44 PM, Adam Murdoch <adam.murd...@gradleware.com> > 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. > > Just to mention it. From looking at your proposals this is for shouldRunAfter > as well as mustRunAfter. > > 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. > > This is the second most voted issue: > http://issues.gradle.org/browse/GRADLE-427 and a very old one. It would be > very cool to fix. > > - 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. > > I would like to see this as part of a whole configuration goodness effort. I > will write more about this in another email. > > - 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. > > That could be part of an integration testing plugin in conjunction with our > upcoming arquillian integration. The current plan is to do this as some core abstractions that the plugin would sit on top of. The concept of set-up and tear-down would live in Gradle, and the specifics of what happens during set-up and tear-down would live the plugin. > > Hans > > > 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. > > > -- > 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 > > -- 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
