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.
[EMAIL PROTECTED] wrote: > It may be better to stay away from a grammar that
gives the
> 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
target-1
target-1
target-2
target-2
When parallelizing that you could earn
target-2
target-1
target-2
target-1
I thought about using a logger per thread
Logger log = Logger.getLogger( targetName + "." + threadNumber );
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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.
