ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alejandro Abdelnur <>
Subject Re: [PATCH] PropertyCopy and Foreach (NEW OPTIONAL TASKS)
Date Wed, 26 Sep 2001 23:55:04 GMT

you reply is in complete different tone of all the previous answers i got from
this alias, it shows an interest on understanding what i'm trying to do before
not good.

as you suggest i'll write up a post-mortem of my project and send it to the

thxs and regards.

ps: i would be glad to participate on the design/development of ant2.

Steve Loughran wrote:

> ----- Original Message -----
> From: "Alejandro Abdelnur" <>
> To: <>
> Sent: Friday, September 21, 2001 11:20 AM
> Subject: Re: [PATCH] PropertyCopy and Foreach (NEW OPTIONAL TASKS)
> > matthew,
> >
> > i've been there already, submitted code doing that, it has been rejected.
> >
> > it is not the first time, or second time, that these features are
> proposed. i
> > think the the folks driving the evolution of ant should start considering
> > these features again, they should listen a little more of what
> developers/user
> > want/need.
> >
> Alejandro,
> Nobody denies that the ability to act on a set of items is a good thing.
> However, it has to be done in a way which is clean and compatible with
> current and future thinking of what ant is. And that thinking comes down to
> 'a declarative means of specifying a build which is readable by other people
> or even yourself months after you wrote it'. Keeping it declarative gives a
> number of advantages, most notably in flexibility of implementation. Keeping
> it simple means that anyone can start using it, and you never end up with
> those horrors of makefiles which big projects tend to acquire.
> If you were to take a quick glance at the ant2 requirements, you would note
> the section in control flow: "The execon and apply tasks can be used to
> iterate over a set of files as the (planed for Ant2) javaon and anton tasks
> will do. ". Which means that the need to iterate has been noted, and will be
> supported. Before that can be done, however, we need to come up with a means
> of specifying a set of items to iterate over, and a clean method of calling
> ant tasks iteratively. I would encourage you to take part in the design
> discussions related to this, and even contribute code, as that way your
> needs and experience can influence the outcome.
> > fyi:
> (out of order)
> > for looping i've implemented the "xantcall" target, extending the
> "antcall"
> > target that supports iterations:
> >
> >     <xantcall target="TARGET" iterate="LIST" iterator="VAR"/>
> >
> > where VAR is the name of the variable that will have the element of the
> > current iteration.
> Its an interesting little hack, but it pushes the boundary of what can be
> called 'declarative', what with all the mention of 'iteration' in the
> statement. I believe what the development team really envisages in terms of
> set/list operations is something more like SELECT in SQL, rather than an XML
> representation of a for() loop.
> One of the big flaws of your approach is that once you have an iterator, you
> need to be able to use it, which is presumably why you've made the next
> change
> > for embedded properties i modified the project helper, so you can use
> embedded
> > variables "a.${b}.c" everywhere.
> Most languages don't let you dynamically produce variable name strings on
> the fly, because it produces scary looking code that is hard to work with.
> Some of the purely interpreted languages are slightly different, APL and VB
> do let you construct a statement in a string, so this kind of thing could be
> done there, but it tends not to be. Instead there are more elegant concepts
> like 'arrays' used to provide the equivalent functionality.
> Overall, I find it hard to see that your two tasks really constitute the
> best possible means of implementing list/set operations, although they
> probably constitute the simplest means of extending the existing codebase to
> do so. As such, if I had a problem today which needs such iteration, then I
> would have no hesitation in pulling down Matthew's iteration package from
> sourceforge. Or pointing someone else at to save them reinventing it.
> But that does not mean that they should be pulled into the ant codebase,
> because they would get in the way of a better soution. So, even if you and
> Matthew do publish a pair of tasks on sourceforge which do iteration, I
> would urge you to work with the rest of the ant-dev community to develop
> that better solution.
> -Steve
> As an aside, from what I've heard of the ant changes made to get your
> project work, with fallback build files in ant, and *DEFAULT* targets, it
> scares me. Either you really are pushing the envelope as to what ant is
> expected to do, or you've chosen a different path to achieve your goals from
> the rest of us. I'd be interested to finding out more about it either
> way -have you a snippet of the project post mortem on build process you
> could pass on to cover not just the process but how the rest of the team
> worked with it?

View raw message