ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Duncan Davidson" <>
Subject Re: Some Thoughts on Ant 1.3 and 2.0
Date Tue, 31 Oct 2000 19:25:35 GMT
On 10/30/00 1:41 AM, "Stefan Bodewig" <> wrote:

> CM> Forgot one of my favourites. I have in the past proposed
> CM> supporting the multithreading of tasks within a target by the
> CM> addition of a boolean async attribute.
> With an implicit join at the end of the target, right? I'm kind of
> sitting on the fence here.

I'm way on the fence on this one. As I have been for a long time. For the
most part, building projects is a step by step process, one step after
another. Yes, there are cases where parallelism is possible and does save
some amount of time -- but it seems like most of these are cases where
people want to deploy things onto servers ... And I'm not sure that it's
worth making Ant more complex to accommodate this.

I also think that since a project is a tree of actions -- it's incredibly
valuable to be totally deterministic in how those actions are executed. This
way, if a build breaks it *always* breaks the same way. In a scenario where
there is parallelism, there is the chance that a build will break one way in
one circumstance (os type, configuration, phase of moon) -- and won't break
in any other case. Debugging such a condition is intrinsically hard.

> When I sat together with Jeff Martin and we thought about things
> missing inside Ant that could help his efforts in Alexandria (kind of
> "build all Java based Apache projects from a single build
> environment"), building things asynchronously popped up quite
> fast. Why not build Tomcat and Cocoon in parallel for example?

For such a use case, I'd much rather see an antconf generate shell scripts
(or whatever) that ran multiple ants simultaneously and joined them using
whatever primitives that the operating system provides. This way, at least
all issues within a build are strictly deterministic.

James Duncan Davidson                              
                                                                  !try; do()

View raw message