ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nasgowitz, Mark (MED, GEMS-IT)" <>
Subject RE: Foreach task)
Date Mon, 11 Jun 2001 21:12:46 GMT
I also feel the foreach task is worth including in Ant. This is non-java
code set but I find Ant works very well.

The foreach task allows me to look in a directory and process all
property files that match. Each property file is then loaded using the
property task. This allows me to have a simple description type file
that contains information needed in the build process such as.....

Now all I have to do is drop in another property file to add another
build job. If I want to suspend one I just move the property file out of
that dir.

My process is not all that simple I process ~8 different builds each
with or without tests then I generate emails to the owners with xml
reports and ftp html pages showing current/past builds along with
trending information.

I plan to keep using the foreach task unless someone has a better

-----Original Message-----
From: []
Sent: Monday, June 11, 2001 3:41 PM
Subject: RE: Foreach task)

I second all this! I am doing something almost identical to your build 
process, only I'm also supporting the ability to deploy to multiple 
environments for development, QA, and production, each with different 
fundamental server configs and different physical characteristics. It 
doesn't make sense to write a build file for each env, since that would 
be a maintenance nightmare, and there is no reasonable way to 
homogenize the environments. If I wrote homegrown tasks to support 
deployment (which involves building sets of property files unique to 
each server instance and THEN moving the files out), it would be 
impossible for my successor to understand without tearing apart my 
code. Additionally, to maintain such a build, the next person HAS TO 
KNOW JAVA, and has to be familiar with developing against the Ant API. 
This simply isn't acceptable. Therefore, as far as I can see, the 
foreach is necessary from a practical point of view.

Also, I'd like to make another point, however feeble:

If you have a pure tool that is relatively useless, what's the point? 
If you want to ensure that tool's survival into the future (which 
everyone does; else why waste time on it?) you have to make it useful. 
And supporting trivial builds that could be done *very* easily with a 
twelve-year-old's shell script is not what people in enterprise 
situations would consider useful.

Just my 2 cents.


-----Original Message-----
From: christopher.berry []
Sent: Monday, June 11, 2001 3:19 PM
To: ant-user
Subject: RE: looping (RE: Foreach task)


As the one who (innocently) began this debate, I will chime in. 
Although I
suspect that this argument has become religious, and as such, neither 
is listening to the other anymore...

In my current build, I have used <foreach> three times, and I do not 
see an
alternate approach. 

1) Loop over all TAR.GZ files in a directory and unpack them -- using a
generic unpack-GZfile-build.xml which takes the base filename as a 
property. I do not think one could do this generically w/ the current 
Tasks, or at least I couldn't figure it out.

2) Loop over every subdir in a directory and call it's build.xml file 
(if it
exists). Our Apps build independent of each other -- calling into a 
common-build.xml. But we must also provide a generic "full build" 
which can build an unknown set of Apps. Of course, one could require 
full-build.xml be edited whenever Apps were added or deleted, but 
that be error-prone?? To me this would be similar to explicitly adding 
to a Classpath, rather than just implicitly adding all JARs in the /lib
directory. One way requires no future intervention, the other constantly
bites you...

3) Loop over every file in a particular directory that matches a 
pattern, and pass it off to another Task. In this case, a home-grown 
which pulls a Version number from the filename, determines the maximum
Version number in use, and writes it to a property for use in a 
Ant Task.

Obviously I could have written a home-grown Task for each of these 
instances. But where is the elegance in that?? Isn't "Don't Repeat 
one of the cardinal rules of development. 

-- Chris

View raw message