> -----Original Message----- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Friday, December 15, 2000 12:34 AM > To: [EMAIL PROTECTED] > Subject: Re: Extensible Attributes > > > Peter Vogel <[EMAIL PROTECTED]> wrote: > > >> Peter Vogel <[EMAIL PROTECTED]> wrote: > >> > >> > 1. Why be so strict about attributes on tags, such that you > >> > throw an exception for any unrecognized tag? > >> > >> Because Ant doesn't expect to see anything that has meaning to > >> something else but not Ant in a build file. > > > > Again, my point is that you have here a lovely, extensible language > > that *can* be easily extended as needed by different organizations > > to support the build environment they need, yet you turn the > > build.xml file into a straightjacket by throwing a parse exception > > for no good reason. To say that the reason ant doesn't like it is > > because ant doesn't like it is the most circular of arguments! > > This is not what I wanted to say - Ant's design doesn't take into > account that somebody out there might want to extend the syntax of the > build file. I didn't even try to give a reason for that design, but > I'll try to do now: > > If Ant ignored unknown elements and attributes, users would have a > very hard time tracking down typos and similar errors: > > <copy forceoverwrite="true"> > > wouldn't be caught. <copydir> has a forceoverwrite, while <copy> has > an optional overwrite attribute - it is valid to not specify overwrite > at all - so the above would essentially become > > <copy overwrite="false"> > > and I think you could spend hours in tracking down the problem.
Well, that's why I suggested making it a warning, perhaps doing like PERL and adding a -w option to show warnings, or add some method (a'la PERL's "use strict;") to indicate that the build file should be parsed in a strict manner. In other words, make it possible to allow people debugging their build files to debug, while allowing people who don't need the strictness to extend the file as needed. Or, if we wanted to get really complex, you could add syntax to indicate how to extend the attributes, but since you want to add namespaces later, I'd skip getting that fancy. > > > Given that it is *trivial* to ignore attributes you don't > > understand, and that it *doesn't* damage the functionality of ant, > > and that it *does* enhance the functionality of environments built > > around ant, why limit yourself and every other potential user of > > ant? > > Because it does damage the functionality of Ant - see above. Only if you ignore the possibility of changing the execption throw to a warning message - see above. > > > Namespaces are nice, but since you aren't using SAX2 right now, you > > are putting off functionality that could be there *today* for some > > nebulous future. > > It's less nebulous than you think. Ant2 will be using SAX2 and I'll > lobby for making it namespace aware. Personally I expect Ant 1.3 to be > released and big efforts put into Ant2 early next year - after we all > have recovered from holidays that is. > > Stefan Whatever. I've modified ant locally to do what we need, but I figured it was a useful enough sort of thing that others might want it as well and it would be nice to not have to integrate the change each time we choose to move to the latest revision of ant. -Peter -- Peter A. Vogel Manager, Configuration Management Arsin Corporation 4800 Great America Parkway Suite 425, Santa Clara, CA 95054
