ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Smith" <>
Subject Re: Whoa Bessie... Was -- Re: [Proposal] AntFarm
Date Mon, 18 Dec 2000 20:07:49 GMT
Hello folks,

Here's another "real world first, revolutions later" email. We have a 
medium-size J2EE project which relies on extensive use of Ant and its 
features. Our build.xml went through approximately 60 revisions since July 
and I've read every message on ant-dev ever since. In other words, just like 
Matt, Diane, Louis and others I am speaking from experience.

First things first: James Davidson vs ant-dev, ack! Isn't there some legal 
precedent where adopted children can choose their parents when they grow up? 
Clearly Ant has been adopted by Conor, Stefan et al and it was their 
commitment to the project that made Ant 1.1 and 1.2 solid releases. 
Furthermore and speaking from experience again revolutions and dictatorships 
have never succeeded in real life and software is an extension of that, aye? 
Splitting the developer base will hurt the users by not having the critical 
mass necessary for features to be discussed, disected and debugged.

HUGE +1 on the "import" part of Matt's proposal: the ability to cleanly 
reference libraries from other projects is extremely useful. This would be a 
very large benefit to projects that have any sort of dependency on other 
projects, be it 3rd party components, javax libraries or components build 
internally as part of another project.

+1 on design document: y'all should be on the same page before you start 
hurling food at each other.

+1 on searching for build.xml being optional and off by default BUT can you 
pleeeeeease make this (whether it's on/off by default) a compile-time 
option? Our project relies on this feature extensively as we have one 
build.xml in a top-level directory so typing 'ant' somewhere deep down in 
the tree without a 'cd $ROOT' is very convenient. Incidentally I disagree 
with Diane re: one build.xml and multiple edits cause many resolves. Fix yer 
project ownership and manage the process rather than asking the tool to fly!

-1 on NOT expanding system properties in ${} and -1 on "blank" shell 
scripts. These two are coupled thanks to the very unfortunate Java VM policy 
of not allowing access to the environment variables. Many projects 
(including ours) have to rely on certain set of environment variables, some 
of these are system properties and others are application "properties" 
(required by some 3rd party lib or component). I've had to modify Ant shell 
script in order to make these available to the build and thankfully I didn't 
have to add all system properties to the command line as well.

Overall assessment of Ant 1.2: very sweet. With <taskdef> the only 
modification I have to make to stock Ant distribution is the inclusion of 
environment variables on the command line used to invoke Ant.


Alex Smith
Insight LLC
Get your FREE download of MSN Explorer at

View raw message