On 15/03/2013, at 1:06 PM, Luke Daley <[email protected]> wrote:
> > > 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. Sure. The plan (in the 'deploying things for testing' spec) is to build something declarative that sits on top of this. You wouldn't say 'finalise this task with that task', you'd say 'this task/resource uses this resource' and Gradle would infer exactly which tasks are required and how to order them. -- 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
