ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Possible bug with <parallel>, <antcall> and depends
Date Thu, 02 May 2002 07:55:24 GMT
On Thu, 02 May 2002, Chad Loder <> wrote:
> At Wednesday 5/1/2002 10:28 PM -0700, you wrote:

>>actually, if your target was
>>     <target name="all-projects">
>>           <antcall target="httpclient"/>
>>           <antcall target="junit"/>
>>           <antcall target="log4j"/>
>>           <antcall target="xerces"/>
>>     </target>
>>with no parallel, I would expect junut to get called as a
>>dependency, as per statement (2)
> It does get called -- only ONCE, as per statement (1). That's
> the desired behavior.

Have you tried it?  It executes junit four times for me.

Ant will execute each target at most once "per project" and each <ant>
or <antcall> is a new project.

I think Ant would be doing what you expect if your removed the depends
clauses from your targets.

> That's much more complex than what I want. All I want is for a set
> of independent tasks to be executed in parallel, while their mutual
> dependencies (recursively) are executed at most once.

That's much more complex than what Ant does 8-)

There is no internal magic bound to parallel that would enable it to
perform dependency checks of any kind.

> I'm a rather handy Java programmer myself and I don't mind writing a
> taskdef for "transitive closure" parallelism. However, I'm rapidly
> getting the impression that this style of build is contrary to the
> spirit of ant for some reason, and I'd obviously like whatever I
> design to be acceptable to the ant maintainers.

It's not so much against the spirit of Ant, but it probably won't work
for you at all.  One of the main problems is <javac>.

Unlike make, Ant will compile all sources at once and this will lead
to race conditions - and even worse, Sun's implementation of javac
will go a long way to make it harder for you to use several javac
invocations inside the JVM in parallel.


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

View raw message