This is merged now.
@Marcin, are you interested in adding support for 'shouldRunAfter' task rules,
to round things out?
The main use case for this is to provide feedback as early as possible during
the build without adding any constraints on execution. Some examples:
* run static analysis before tests
* run unit tests before integration tests
* run the unit tests for a project before compiling those projects that depend
on it
The idea is to add a very weak task execution rule that only provides hints for
execution order and implies nothing else. So, if A shouldRunAfter B then:
1. If A or B are not scheduled to run, ignore the rule.
2. Run A after B only if there are no other contradictory rules on the ordering
of A and B. That is, ignore cycles introduced by shouldRunAfter rules.
3. The dependencies of A shouldRunAfter B and its dependencies.
4. If B fails or is not run, A can still be run.
5. If there is an idle worker thread and A is the only task whose dependencies
have been satisfied, then run A regardless of whether B has been run or not.
That is, prefer running the task over an idle worker thread.
Similar to mustRunAfter, but different in #2 and #5 above.
There are plenty of other things we could also do with the task rules, if
you're interested in any of this:
* Move the task rules to a specific namespace rather than have the methods
directly on Task.
* Change Ant import to use shouldRunAfter to emulate Ant's target ordering
rules.
* Improve finaliser support for tasks that are skipped. For example, if a
SourceTask has no source files, then don't run the finalisers for this task.
* Add a replacement for Task.enabled that does not run any of the dependencies
of the task that are not otherwise required.
* Add conveniences to declare rules like 'shouldRunLast',
'mustRunAsEarlyAsPossible', and so on that work on groups of tasks.
* Handle setting up and tearing down test resources as required. For example,
create a database instance and start the web container if the integration tests
are to be run, and clean everything up when finished with them.
* Add resource usage aware parallel task scheduling. For example, don't run two
integration test suites in parallel if they both need exclusive access to the
database instance.
* Add input and output file aware parallel task scheduling. For example, don't
run the clean and compile tasks in parallel.
* Add support for using the output of a project to configure another project,
so that we schedule some tasks, run them, configure some things, then schedule
and run more tasks.
* Add a replacement for `gradle.taskGraph.whenReady {}` that is evaluated early
in the configuration phase rather than at the end.
* …
On 13/05/2013, at 10:10 PM, Marcin Erdmann <[email protected]> wrote:
> On Mon, May 13, 2013 at 12:51 AM, Adam Murdoch <[email protected]>
> wrote:
>
> On 13/05/2013, at 5:08 AM, Marcin Erdmann <[email protected]> wrote:
>> Please let me know what are your current plans for this piece of work.
>
> The plan is to get your work into the 1.7 release. We'll merge it into master
> some time soon.
>
>
> That's great news! I created a pull request for this:
> https://github.com/gradle/gradle/pull/154.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
