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 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
