> -----Original Message----- > From: Edwin Goei [mailto:[EMAIL PROTECTED]
[...] > On the other hand, if both the APIs and implementation > classes are in a > single jar file, it would not totally eliminate the problem, > however, it > is simplified. You would still have to tell users to put xerces.jar > before xalan.jar, but at least you don't have to deal with an > xml-apis.jar file on the classpath where it may be difficult to know > which version it is (the xerces or xalan version). Each solution has its limit there. Simply because we don't want to put the hassle on the user and avoid him to put 3 jars in the classpath we package everything in a single one. More than often in real time case it appears you have to deal with old versions because you did a development tighted to it (Say parser.jar and the binding) and can't switch to a new version easily (you simply cannot allocate time for it), and you want to benefit from some recent version of Xalan 2.x for some other features (extended support of xsl) and xt for its speed in some area. All this must work together. Add to this that you are using castor that needs xerces for serialization and that it must run in some version old version of tomcat or weblogic that mess everything and you are in a real mess. I even encountered the case using OpenXML about an incorrect signature for a method in a DOM interface... The fact that everyone want to bundle everything in a jar makes it a pain because your only solution would be to hack the jars and remove all these and explicitely separate this in dom1.jar, dom2.jar, sax1.jar, sax2.jar because you end up with dependencies that you cannot control in a web application and even sometimes you end up with circular dependencies. > In the above example, I am neglecting the fact that there may be > multiple versions of xerces and xalan, also, which probably > makes things > more complicated. Yep. > For crimson, here is the way I think it should work... There > should be > only a single jar file: crimson.jar that contains everything: both > implementation and API classes. This is the way that the > latest version > of crimson works: version 1.1.3. I noticed that Ant uses an older > version of crimson that has jaxp.jar. This is similar to the way > xerces.jar and xalan.jar are packaged. This makes it easy for > developers and users of the software since you do not have to worry > about different versions of the api jar file that must match the > implementation jar file and there are less jar files to add to a > classpath. I think that no one professionally develop anymore with adding jar in the classpath by hand. After all Ant is there for this. :-) IMHO I think it is not an issue even for newbies. > Actually, I don't think I ever supported a separate xml-apis.jar file, > someone else created the build.xml file to produce that jar file. A > while back ago, on [email protected], I posted 3 > different options > for the xml-commons code and which of the options I thought was best. > They may be on http://marc.theaimsgroup.com. Yep I followed the thread a little bit and noticed that nearly everybody was in favor of putting everything in the jar for 'ease' of use. It probably makes it easier to use xalan and xerces in the command line, but certainly not in a whole app that use lots of third-party related to XML. > BTW, it looks like the latest Ant dist comes with crimson 1.1.1. I'd > recommend upgrading to at least the latest version 1.1.3. Stefan did the update to 1.1.3, thus this thread. Stephane -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
