> From: Peter Donald [mailto:[EMAIL PROTECTED] > > > there are some places where a task (or a few tasks) are completely > > appropriate, for example building installation packages. But there > > are others where a "roll your own" philosophy detracts from > the goals > > of ant. I'm quite happy to write tasks, etc. to meet my needs, and > > I have done so where I felt it was appropriate. > > right. > > But neither of these points have any correlation with your > point. Your > contention seems to be that we should add flow control tasks > and their > ancillary support. This would in effect determine structure > of build at > runtime rather than before execution began. It would also > have a number of > side effects. Yet the only reason for using this above > something like XSLT is > that you don't want to learn XSLT. Naturally this is not an > arguement that is > going to convince me. >
Actually, this reliance on some outer layer to do half of the things people are asking for, is troublesome. The more we veto things from ant and put them in some "external" macro processor, the more ANT will become that external macro-processor. The more the work of the macroprocessor is required, the more presure to standarized the languge it uses, to learn it by even the simplest of users. How does one writes the equivalent of a "fileset" in XSLT? Can I define property-like things that apply during the macro phase? How does one guarantees that I can ship my templates around and they can be used by anyone? Do we need to support some mechanism fora template library? Are templates relative to basedir? All these issues and more will become the center of life for ANT build writers because templates will be more and more indispensible, the more we shufle in there. Now, this does not mean we should just allow everything and anything about control structures. But I think there is certaintly space for some basic, well defined, set operations that can preserve things like inmutability. Anyway, just food for thought. Jose Alberto
