On 14/03/2013, at 15:21, Adam Murdoch <[email protected]> wrote:
> > On 15/03/2013, at 7:41 AM, Daz DeBoer <[email protected]> wrote: > >> >> >> On 12 March 2013 20:39, Adam Murdoch <[email protected]> wrote: >>> >>> >>> >>> On 13 March 2013 11:36, Daz DeBoer <[email protected]> wrote: >>>> Hi Marcin >>>> >>>> You pull request has been merged with a few tweaks. The most important of >>>> those was to fix DefaultTaskGraphExecuter so that it is considered >>>> "populated" whenever a task has been added. Without this fix 'gradle >>>> --dry-run' was broken. This breakage was picked up by >>>> TaskExecutionIntegrationTest, which I converted to Spock and added a few >>>> "mustRunAfter" test cases. >>>> >>>> Other than that, it looks great. Get this into the user guide and I'm sure >>>> it will be a popular feature. >>>> One minor improvement would be to support the map-based syntax for >>>> mustRunAfter, in a similar way to dependsOn: >>>> >>>> task foo(mustRunAfter: 'bar') >>>> >>>> Not sure what our plans around supporting different parameters in this >>>> way, but it feels like a natural fit. >>> >>> Let's see what falls out of the next story first. >>> >>>> >>>> On 11 March 2013 17:00, Marcin Erdmann <[email protected]> wrote: >>>>> On Mar 11, 2013 1:32 AM, "Adam Murdoch" <[email protected]> >>>>> wrote:> >>>> >>>>> > Personally, I would love to see some more work on task execution model, >>>>> > if you're interested in working on it. >>>>> >>>>> I actually wanted to work on making copy task encoding-aware but it now >>>>> seems to me like working on the task execution makes more sense and will >>>>> be more benefitial to a bigger group of users. I also know the code in >>>>> that area pretty well now so hopefully I should be able to get stuff done >>>>> quite quickly. Any design docs and/or implementation hints on those >>>>> 'finalizer' tasks would be highly appreciated. I'm happy to start on it >>>>> after I'm done with the mustRunAfter docs. >>>>> >>>> >>>> I agree that it would be fantastic to keep moving forward on improving >>>> task execution. Our Ant-import support will never function properly >>>> without "shouldRunAfter", and "finalisers" as described by Adam would be >>>> great for a whole bunch of use cases. >>>> >>>> The reporting spec >>>> (https://github.com/gradle/gradle/blob/master/design-docs/reporting.md) is >>>> probably the only real design doc for these changes. >>> >>> It is the design doc for the changes. >>> >>>> You'll see that there are a few integration tests that we don't yet have >>>> coverage for wrt "mustRunAfter". If you are willing to add those in, that >>>> would be awesome. The spec is a little inconsistent regarding whether the >>>> dashboard task should run if a reporting task fails: I think we're happy >>>> with it as implemented now, with the next stories taking this a little >>>> further. >>> >>> We are. I've updated the spec to (hopefully) be more consistent. >>> >>>> >>>> The best design discussion I can find regarding finalisers is in a _very_ >>>> long email thread on the dev list. Here's a link to the middle of it: >>>> http://gradle.1045684.n5.nabble.com/Gradle-reporting-improvements-tp5710408p5710809.html >>> >>> I've written up the current plan for finalisers in the spec. This is really >>> a write-up of the current state of the discussion, rather than a concrete >>> plan: >>> https://github.com/gradle/gradle/blob/master/design-docs/reporting.md#automatically-add-dashboard-report-task-to-task-graph >>> >>> Please (everyone) have a read and give feedback. In particular, we need to >>> sort out how the DSL is going to look. >> >> As is often the case, the best I can do is summarise and attempt to clarify >> in my own head. Hopefully this helps others as well. >> >> So a single task can 'finalise' a set of other tasks? I'm not sure that >> 'finalise' is the perfect term, but I can't think of anything better. >> I was initially confused by the expression "A is a finaliser for B", because >> that seemed to preclude "A is a finaliser for C". But if I say "A finalises >> B" and "A finalises C" it makes sense. It's not a real distinction, but the >> language can make a difference to understandability. >> >> If we say Task A "finalises" Tasks [B,C,D], then: >> - presence of A does not force any of [B,C,D] to be in the graph >> - A will not run if none of [B,C,D] run > > A's dependencies will not run either. This is a 'should' constraint, as in: A > and its dependencies should not be executed of none of B, C or D are > executed, but it doesn't matter if A or any of its dependencies are executed > for some other reason. > >> - A will run after all of [B,C,D] that do run >> - A will still run even if any of [B,C,D] fail > > This is a 'must' constraint: If any of B, C or D are executed, then A and its > dependencies must be executed regardless of whether B, C or D succeeded or > failed. And regardless of whether the build is executed with `--continue` or > not. > > A couple more: > > - The presence of B, C or D in the graph forces A to be added. > - I'd also add that A should run as early as possible (e.g. generate the > dashboard immediately after the last reporting task has completed, or stop > the web container as soon as the integration tests have finished). I'm not sure I'd want to express this via "finalises". What I want to say is: stop the container when it's no longer needed. I don't want to have to say the stop task finalises all the tasks that use the container. > > >> >> I imagine that we'd have something like: >> >> tasks.withType(Reporting) { reportingTask -> >> buildDashboardTask.finalises(reportingTask) >> } >> >> tasks.withType(Checkstyle) { checkstyleTask -> >> task.add("${checkstyleTask.name}Report", CheckstyleReport) { // >> implements Reporting >> finalises checkstyleTask >> } >> } > > This would force us to configure every task in order to determine which tasks > finalise a given task. So, I'd move the DSL to the task that is to be > finalised, so that we can configure tasks on demand. Perhaps something like > this: > > tasks.withType(Reporting) { > finalisedBy(buildDashboardTask) > } > > > -- > 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 >
