--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > I agree - and I think Peter does as well. The > thread started out with > Peter asking which combination of tools he should > use to create his > prototype - so we can evaluate the impact - and > somewhere down the > thread I said I wouldn't care too much ...
Ok, I'll accept that. It just seems that the disc. has turned to "is it right or not". Peter *seems* to argue that <projectref> is "wrong" or "bad" - and my point of view here is, if it doesn't change the core, it isn't bad. If you don't like it, don't use it. I have NO problem with that. > Most of the problems people have with Ant - at least > those people > asking for loops and such - stem from the fact that > they are trying to > make Ant fit the paradigm they've been using in > their respective build > systems before they switched to Ant IMHO. Not necessarily. That's one issue I have with some of these discussions. You can't automatically make that assumption. I will agree that in many cases, you are correct, but there are still cases such as myself who *have* shifted gears but still want new features (such as iteration). It happens that the Ant syntax encourages the use of iteration, etc. in certain circumstances since the Ant targets do not operate directly on files. There are cases and files which are not currently covered by tasks (eg. non-Java files) that could be handled more elegantly with some of these features we ask for. (And no, I don't have an example ready at hand - I'm just on my soapbox.) > My major concern here is: Give them static templates > and they don't > even bother looking up another way of doing what > they need with Ant. > They'll talk about the complexity of XSLT and say > Ant would be > difficult to learn and all that. I have to agree with your point, but on the flip-side, many of those same people will never make the effort to learn XSLT or any other solution, either. I would bet that such things would probably never even occur to them. In response, they will end up writing horrible Ant files. Is it really the team's charter to prevent that from happening, or is it instead to ensure that 90% of build file writers *can* write clean files? It seems a central issue of many of these discussions is the composition of the target market for Ant - novices or experts. My target audience is of course, myself, expert. But I certainly can't dictate that to the team! ;-) Perhaps clarifying who Ant is intended for would help keep some of these disc. from getting antagonistic. (There it is again - ant-agonistic.) > If we have some static templating mechanism I > strongly wish that we > brand it as "this is not Ant". Agreed. I have used XSLT "templating" myself, and I'm very happy with the way it lets me assemble simple new pseudo-tasks in much less time than it takes to write the Java. However, as Jose pointed out, there is a huge danger of Ant fragmenting into a different local "dialect" for every project out there. I also think external templating (or configuration) carries a much greater potential for abuse from careless programmers (which Peter is concerned about) than do most potential new Ant features. If this fragmentation occurs, then no one is using "Ant", but rather their local build language. No, you can't call that Ant. Also, Jose's points about the effect on Ant generators and editors is an excellent one that I had not previously considered. (Probably because I don't like generators much myself.) Even though I have used the XSLT approach and do like it, I am expert at this stuff. I cannot see recommending it for widespread use, as it is remarkable similar to the Imake debacle. Imake is a powerful tool, but saw very little use because of its complexity, not the least of which was the use of three separate languages (the Imake "language" - cpp, the make language - itself incorporating several, and the local dialect Imake was to process). IMHO, any approach that treats Ant the same way will most likely meet the same reception. Any solution that requires additional languages to complete the build will be necessarily more complicated to learn and maintain. For that reason alone, I personally would rather see the Ant core language itself become more expressive. Ok, enough soapbox for today. ;-) > > There is obviously demand (and therefore need) for > this type of > > functionality, so who are we to say it is "wrong"? > > Which functionality exactly? I was specifically referring to the templating functionality - in whatever implementation - but this could equally well apply to other controversial features. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
