On 25/06/2013, at 9:09 AM, Marcin Erdmann <marcin.erdm...@proxerd.pl> wrote:
>
>
>
> On Tue, Jun 25, 2013 at 5:57 AM, Adam Murdoch <adam.murd...@gradleware.com>
> wrote:
>
> This is merged now.
>
> Got super excited and wanted to try it out using a nightly build but got it
> to throw an IndexOutOfBoundsException when:
> - b depends on a
> - a is finalized by c
> - b is finalized by c
> Just the regular start server -> run integration test -> shutdown server
> scenario... This is really bad, wonder how I got such a common use case
> wrong, the coverage seemed to be really good, yet it still happened. I will
> work on a pull request for that tonight.
We are cutting RC-1 early next week. It would be good if we good at least get
some assessment of this done before then so we know the risks.
If you want some extra eyes on it let me know and I can help out.
>
>
> @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.
> * …
>
> Thanks for the writeup Adam. Feels like shouldRunAfter is a natural
> continuation of my work around the area of task scheduling so I'll stick to
> and have a crack at it whenever I have a spare evening.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
