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