ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: executing task for each file in file set
Date Tue, 12 Jun 2001 12:15:29 GMT

=> On Mon, 11 Jun 2001 17:56:31 -0700 (PDT), Roger Vaughn <>

>>> Say we'd add foreach to the core - and I'm more and more leaning towards
>>> it (making myself a heretic, I guess 8-) - and we already have those many
>>> cases where we successfully anticipated the need for iterations like
>>> javac, execon, apply and in the future anton, javaon.  What can we do to
>>> make user chose the "right" thing?

Having now read the requirements doc for ant2, I think that keeping foreach
out of the core, but anticipating that those who want it will grab it, is the
best way to present the 'right' way without being draconian.  I, for one,
would drop out of the debate were that decided.

> First we had <exec>.  Then came <execon>, i.e. exec for each member of a
> fileset.  Now we see anton, javaon, etc. in the future.  But is this the start
> of a trend: exec/execon, ant/anton, chmod/chmodon, delete/deleteon,
> echo/echoon, etc.?  (Yes, I know some of these deal with filesets natively -
> I'm simply making a point.)

> Are we now going to have individual and iterating versions of every task?

I assert that tasks should, where this is sane, operate on a list of items.
This list may only contain one item.

> It would seem to make far more sense to me to extract the iteration code into
> its own construct, and keep the individual tasks pure.  This would seem to
> involve far less code, simpler maintenance, and more flexibility in the build
> files.

It also formally forces task writers to accept heinous inefficiencies when it
is appropriate to operate on filesets.

foreach (distfiles)  add one file to a tar ... ? 

Viewing builds as functional transformations on filesets is a powerful
abstraction.  I think we should still phrase things in that idiom wherever
practicable, (which I still say is everywhere) but let people use the more
complex (IMHO), but evidently more comprehensible, iterative idiom when they
feel the need.

- Allen S. Rout

View raw message