On Thu, Apr 11, 2013 at 10:44 PM, Adam Murdoch <[email protected]>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. > 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. 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 > >
