DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5302>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5302 Sealing Violation ------- Additional Comments From [EMAIL PROTECTED] 2001-12-11 13:56 ------- Ok, sorry if I seemed harsh...to a certain degree it was just venting 'cause it seemed so agrivating to have written what I hoped would be a great article on writing Ant tasks, only to watch it turn into a big article full of "well, we couldn't do this, and we couldn't do that, and we couldn't do the other thing" all because of odd technical decisions (few directly relating to Ant, of course) causing conflicts that in this case had no resolution. I suppose what should be done by Ant at the very least is to update the documentation on writing tasks and give the warning about 1) sealed jars, and 2) jars that include XML compilers that overlap the compiler that Ant has chosen (last I saw, it was JAXP + Crimson, right?). In addition, Ant could catch the SecurityPermission exception that's thrown by a sealed-jar conflict and give a more user-friendly message about it. JAXB was "early access" -- meaning it was really just a bunch of guys making something as a proof of concept that Sun suddenly up and said "hey, that looks stable enough -- go make a jar and we'll put it out there". It actually doesn't have jaxp in there as such, but the earlier version of Sun's XML parser before they called it Crimson, and its thus only Sax1 and Dom1 compliant (and would likely conflict with Ant as a result). A part of me does wonder how Ant and other Xml tools out there expect to deal with Java once 1.4 becomes official and more widespread, since it includes JAXP and Crimson automatically, which results in killing, effectively, the "market" such as it is for Xerces and other parsers (sure, you could override the property and use something else, but who would? that's how Microsoft has taken over everybody's lives these days...), and locking the API down to Sax2 and Dom2, making future improvements in the API very difficult. One consideration may be to put some of the "load" of handling external jars in external tasks on the developer (or at least the guy writing the build.xml file with the taskdef call). The taskdef might specify the location of external jar files that have the task implementation and the supporting jar files, and perhaps Ant could run that task in its own ClassLoader. But that definitely sounds like a 2.0 "consideration" that needs to be weighed against the amount of times this sort of conflict happens. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
