On 13/05/2013, at 5:08 AM, Marcin Erdmann <marcin.erdm...@proxerd.pl> wrote:
> I managed to get some more work done on implementation of task finalisers: > see the last 3 commits at https://github.com/erdi/gradle/tree/finaliser-tasks. Excellent. Thanks so much for this. > > I applied all the suggestions from the latest review (renamed finaliser to > finalizer and added finalizer edges to task graph to resolve finaliser task > dependencies only once) and rebased the branch to the latest master so that > it's easier when you decide to merge it. I also implemented integration test > scenarios for finalisers added to the design spec some time ago by Adam. > Currently the following scenarios are failing and are marked with @Ignore > (Given a.finalizedBy b and a.dependsOn c and b.dependsOn d): > - gradle a run c only when a is disabled and all tasks are added to the task > graph > - gradle a run c only when a.onlyIf { false }. All tasks are added to the > task graph. > > If I understand it correctly ("We want to run the finalisers if the task was > started, regardless of what it did. (...) Of course, this means that we'll > run the finalizer more often than we need to (including when the finalized > task is disabled). This is fine for now, and we'll make this better as a > later step. The contract for a finalizer is 'should not run' not 'must not > run' when the finalized task is not executed.") we want to leave it as is for > now. I think that's right. At this stage, the contract for a finaliser is that it should not run if the finalised task is not run, but it can, at Gradle's discretion. That is, it is a 'should not' rather than a 'must not' constraint. For the use cases we're current using finalisers for, this is fine: If the dashboard report is generated or the web container stopped when it doesn't need to be, that's fine for now. I suspect we're going to split finalisers into two different but similar constraints: - A task that augments the output of another task, such as reporting tasks, where they are logically part of a large whole. - A task that cleans up the work of another task, such as stopping a container or cleaning up a test database instance. > > - gradle b a fails with a circular dependency failure. I think that this is > not right as currently the contract seems to be that order specified on the > command line is a should and not must ordering. Right. We can fix this as a second piece of work, as a tweak to how we traverse the assembled graph. > > Please note that I changed the regexp for extracting executed tasks in > OutputScrapingExecutionResult to also include failing tasks to be able to > implement some of the scenarios. I noticed that failed tasks are included in > executed tasks for InProcessExecutionResult and also asked Luke if that is > the right thing to do. > > Please let me know what are your current plans for this piece of work. The plan is to get your work into the 1.7 release. We'll merge it into master some time soon. -- 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
