On Fri, Apr 12, 2013 at 10:41 PM, Adam Murdoch <adam.murd...@gradleware.com>wrote:
> > 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. > Cool. Hans
