ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kyle R. Burton" <>
Subject Re: Parallel processing option for subant? - Parallel Ant Subsystem?
Date Wed, 12 Oct 2005 15:48:57 GMT

I'm sorry I haven't participated in this thread until now.  We needed
a parallelizing build tool where I work and have made a modification
to ant that executes independent targets in parallel where possible. 
We are not using most of the standard ant tasks in our parallel
builds, but have executed our processing several times and the
parallelization works reliably for us.

We're still in the midst of the project and haven't been able to take
the time to clean up the code and submit an official patch that meets
the guidelines.  I'm attaching the patch anyway so that you have the
opportunity to evaluate it.  It was created against the stable release
1.6.5 and makes minimal changes to the existing code (there are
changes in Main, Project and DefaultLogger).  I have permission from
my employer to submit the changes back to Jakarta.

The approach is pretty basic.  We created a custom executor that
implements executeSortedTargets.  If the parallel ant subsystem is
enabled (ant.pants=true), this alternate executor is invoked.  It
builds a dependency matrix of all of the targets and executes
concurrently any that can be based on the configured dependencies in
the build.xml file.  The default logger seems to get a bit confused
about which task/target is emitting messages.  We haven't tracked that
issue down yet.  The changes have been pretty stable for us.

Thanks for your effort and consideration.

Kyle R. Burton

On 10/12/05, Matt Benson <> wrote:
> --- Jeffrey E Care <> wrote:
> > Steve Loughran <> wrote on
> > 10/12/2005 07:50:04 AM:
> [SNIP]
> > > to an extent <parallel> is the most prone to race
> > conditions, as it is
> > > running stuff in the same project. a subant
> > running in parallel is
> > > likely to share much less, just a FileUtils
> > instance and maybe some
> > > references handed down.
> >
> > Is it same to assume that we'll be running against
> > JDK 1.2 or greater? If
> > so we could possibly convert FileUtils (or any other
> > class with a static
> > "getInstance" singleton accessor) to use
> > ThreadLocal.
> To interject, I can't recall ever having seen anything
> in FileUtils specifically that would not be
> thread-safe.  There is no instance data and no static
> data is modified after class initialization.
> -Matt
> __________________________________
> Start your day with Yahoo! - Make it your home page!
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Wisdom and Compassion are inseparable.
        -- Christmas Humphreys                  

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message