ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Holzwarth <>
Subject Re: AW: extended parallelism
Date Wed, 19 Dec 2007 14:33:40 GMT
The problem with giving a command line option is that ant is effectively a set of rules. The
rules form a tree and the dependencies give a list of targets that are to be executed before
the current target. There would have to be some intelligence in the build file that would
show ant which tartets could be completed in parallel. For example, if you are using ant to
compile C programs, the obj files that the executable requires must be completed before the
linkage stage. There are areas where parallel processes can be leveraged, but ant will not
be able to determine those places. In my experience, even the programmers who have written
the code have difficulty identifying those places.

In my case, there are times where parallem processing could be helpful. I retrieve the latest
copy of all files from the repository for builds, I retrieve the CM log information, I create
the release boiler plate file using information in a property file that is loaded at startup.
These could all be executed in parallel. One part of the build that could not be executed
in parallel is creation of the zip file that includes only the HTML files that changed since
the previous release. These files are copied from the complete release zip files and can't
be attempted until the zip files with the complete set of files is available. wrote: > It may be better to stay away from a grammar that gives
> rules and use something like:


You could provide another executor ;)
In my approach I dont want the user to change the buildfile. Just set
the property on command line.
   ant -Dant.executor.class=ParallelExecutor ...

> How do you propose to handle potential fatal/non fatal 
> errors? 

The implementation collects thrown BuildExceptions from the target.
A target will be started, if no dependend target has failed. 
Why not try to build the jar only because the test fails? If there is a
dependency you should 
describe that dependency using the depends-attribute.

>If target a exits due to an error, should there be an 
> option to kill a or allow it to complete (similar to 
> failonerror="yes/no")? If both a and (b,c) must succeed for 
> d, should a be killed if b or c fails? 

If you want to have that, use 
If there is no dependency - why stop the build?

> It was not difficult, but error handling was always the issue.

My biggest problem is spreading all the logs. In a single thread you
have output like
When parallelizing that you could earn

I thought about using a logger per thread
    Logger log = Logger.getLogger( targetName + "." + threadNumber );


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

Thank you,
Chuck Holzwarth
(804) 403-3478 (home)
(540) 335-3171 (cell)
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message