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 will run after all of [B,C,D] that do run - A will still run even if any of [B,C,D] fail 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 } } So running: 'checkstyleMain' ===> 'checkstyleMain', 'checkstypeMainReport', 'buildDashboard' 'check' ===========> 'checkstyleMain', 'checkstyleMainReport', 'checkstyleTest', 'checkstyleTestReport', 'buildDashboard' -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
