I think I'll manage on my own, but thanks for the offer, will keep it in
mind. Hopefully it will be easy to fix, I will have a look at it tonight
and let you guys know.
On Tue, Jun 25, 2013 at 12:00 PM, Luke Daley <luke.da...@gradleware.com>wrote:
>
> 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
>
>
>
