ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: looping (RE: Foreach task)
Date Mon, 11 Jun 2001 22:00:21 GMT

=> On Mon, 11 Jun 2001 13:18:50 -0700, Christopher Berry <>

> 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 side
> is listening to the other anymore...

I like to view myself as devoted, but not dogmatic. ;) I'm sensitive to the
dead-horse-beating, and at least attempt to keep from just repeating.  Dang,
that rhymes.  I'm sorry.

> 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 supplied
> property. I do not think one could do this generically w/ the current Ant
> Tasks, or at least I couldn't figure it out.

I'm not as focused on the current tasks as I am on the model, so I may
advertise functions not implemented.  I certainly respect the difference
between 'how the model says it should be done' and 'how I can do it Right The
Devil Now'.

That said, I'd suggest

<fileset name="tarry" dir="foo" include="**/*.tgz" />

<tar fileset="tarry" destdir="${interesting-place}" />

> 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 shared
> common-build.xml. But we must also provide a generic "full build" procedure,
> which can build an unknown set of Apps. Of course, one could require that
> full-build.xml be edited whenever Apps were added or deleted, but wouldn't
> that be error-prone?? To me this would be similar to explicitly adding JARs
> 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...

... The problem I have answering this one is how much I'd do your build
environment differently.  Hm.  I agree you don't want to hand-edit the main
build.xml every time something changes.

The way I'd solve this problem in app management ( which is not necessarily
the same as the problem in ant ) is to have a separate task/script/whatever
that reproducably generated a list of the interesting apps.  This would
probably start with something vaguely like a

find . -name build.xml -ls \
       | decide-if-my-map-needs-updating \
       | munge-list-into-properties-enumeration  \
       > to-be-included-in-build.xml

But I tend to see it as a meta-build problem.  And you see, the problem is
-not- "how do I run ant on a bunch of dependant build.xml files", but rather,
"how do I specify a changing set of build.xml files, oh and I think I'd like
to do it -this- way."

> 3) Loop over every file in a particular directory that matches a specific
> pattern, and pass it off to another Task. In this case, a home-grown Task
> 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 subsequent
> Ant Task.

<fileset name="groan" basedir="${dir}" include="**/pattern"/>

<homegrown fileset_name="groan" propfile="${prop.file}" />

<othertask propfile="${prop.file}" />

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

Oh, repetition can be lazy too. ;)   

- Allen S. Rout

View raw message