On 11 April 2013 09:51, Marcin Erdmann <marcin.erdm...@proxerd.pl> wrote: > Thanks for letting me know that Adam is not around. I didn't want to sound > pushy or something, I was just curious. > > The docs are already there > (https://github.com/erdi/gradle/commit/be0300142269d842b5873b562f57acc3be81cb16). > I did my best but you'll probably rewrite them all as usual, Daz. ;)
In that case, I'm sure a spike of "shouldRunAfter" wouldn't go astray! > > On 11/04/13 16:22, Daz DeBoer wrote: > > Thanks Marcin. I think the 'current state' is that this is in Adam's review > backlog, and he is on vacation this week. > The next step would almost certainly be some samples and documentation for > task finalisers, so if you'd like to work on those that would be fantastic. > > Daz > > > On 11 April 2013 09:07, Marcin Erdmann <marcin.erdm...@proxerd.pl> wrote: >> >> What is the current state of this? Do we want to put it on the backburner >> for now or should I submit a pull request for that piece of work? >> >> >> On 02/04/13 01:16, Adam Murdoch wrote: >> >> >> Thanks so much for this. I'll review it soon. >> >> On 02/04/2013, at 8:52 AM, Marcin Erdmann <marcin.erdm...@proxerd.pl> >> wrote: >> >> You can find task finalisers implementation in the following branch: >> https://github.com/erdi/gradle/tree/finaliser-tasks. I think I implemented >> everything that was mentioned regarding task finalisers in the previous >> threads on the topic as well as in the design docs for reporting. The next >> step would obviously be adding docs but as usual I would be grateful for a >> review of the code. Please let me know if I missed something feature or >> test-wise. >> >> Solutions I went for: >> - finaliser information is lazy (using a DefaultTaskDependencyInstance) >> and is only stored on finalised tasks >> - new states for TaskInfo: MUST_RUN, SHOULD_RUN (renamed from READY), >> SHOULD_NOT_RUN >> - finaliser tasks and their dependencies added to the graph (when >> finalised task is added) are in SHOULD_NOT_RUN state >> - finaliser tasks (but not their dependencies) mustRunAfter finalised >> tasks >> - to make sure that finaliser tasks are executed they are being added as >> an entry task (just like if they were passed to addToTaskGraph()) >> - if a finalised task did any work then all its finaliser tasks and their >> dependencies are switched to MUST_RUN state >> - when there were no failures all tasks that are in MUST_RUN and >> SHOULD_RUN states are executed >> - in case of a failure all tasks apart from those in MUST_RUN are skipped >> from execution >> - to force finaliser tasks to run ASAP a mustRunAfter ordering is added >> from any task that depends on a finalised task to the finaliser task; this >> should probably a should run after ordering, but there is no such thing >> available yet; there has to be a decision made what is more important - >> running those tasks ASAP or avoiding unnecessary circural dependencies when >> a is being finalised by b, b depends on c and c depends on a (currently an >> implicit mustRunAfter is added from c to a causing circural dependency) >> - build dashboard task is now a finaliser for all Reporting tasks >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >> >> -- >> 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 >> >> > > > > -- > Darrell (Daz) DeBoer > Principal Engineer, Gradleware > http://www.gradleware.com > Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: > http://www.gradlesummit.com > > -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
