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.
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. 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.
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
Thanks again for the contribution.
--
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
