On 15/03/2013, at 2:04 PM, Adam Murdoch <adam.murd...@gradleware.com> wrote:
> > On 15/03/2013, at 1:06 PM, Luke Daley <luke.da...@gradle.biz> wrote: > >> >> >> On 14/03/2013, at 15:21, Adam Murdoch <adam.murd...@gradleware.com> wrote: >> >>> >>> On 15/03/2013, at 7:41 AM, Daz DeBoer <darrell.deb...@gradleware.com> wrote: >>> >>>> >>>> >>>> On 12 March 2013 20:39, Adam Murdoch <adam.murd...@gradleware.com> wrote: >>>> >>>> >>>> >>>> On 13 March 2013 11:36, Daz DeBoer <darrell.deb...@gradleware.com> 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 <marcin.erdm...@proxerd.pl> wrote: >>>> On Mar 11, 2013 1:32 AM, "Adam Murdoch" <adam.murd...@gradleware.com> >>>> 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. Rad. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com Join me 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
