RE: Discussion of: (Xerces and Xalan Overlap) (xalan.jar contains jaxp class files)

[Tim McCune <ti...@channelpoint.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ugh.  Why do I think this is going to get worse before it gets
better?  I don't have a good solution for the overall problem, but
one small step that might help matters a little bit would be to start
using version numbers on jar file names (e.g. jaxp-1.1.jar,
xalan-2.0.jar).  We do this on _all_ jar files here, and also rename
all third-party jars that we include in our projects.  Our latest
build results tree contains 371 jar files of varying names and
versions, so you can see how critical this is for us.  I would also
like to see stuff like "dom-2.0.jar" included in xerces as a
dependency, instead of just blindly bundling dom, jaxp, etc in with
the main jar.  This might alleviate things as well.

> -----Original Message-----
> From: Shane_Curcuru@lotus.com [mailto:Shane_Curcuru@lotus.com]
> Sent: Friday, March 23, 2001 7:53 AM
> To: xalan-dev@xml.apache.org
> Subject: Discussion of: (Xerces and Xalan Overlap) (xalan.jar
> contains jaxp class files)
> 
> 
> A brief overview on the following two issues, as far as I 
> understand them.
> 
> The packaging for Xalan-J was meant to be standalone, mainly 
> to ease the
> life of end-users.  That means someone can get a Xalan-J 
> distribution, and
> it will include everything in it needed to rebuild, and 
> everything needed
> to run Xalan will be in one jar: xalan.jar (plus an XML 
> parser of course:
> that's why we include xerces.jar in our distribution).
> 
> This can cause a problem when a user has copies of any
> standards-based files already in their environment.  Although
> xalan.jar includes
> version-matched copies of all the standards-based files 
> inside itself, if a
> user has standards-based classes or jars earlier on the classpath
> than xalan, we might end up with the wrong versions of things 
> (hence several
> FAQs about NoSuchMethod errors, etc.)  This can also cause 
> confusion, like
> now, when people wonder why we have duplicate code with other 
> common apache
> packages.  Note that many modern JDK versions 1.2 and later 
> also include an
> extensions directory that 'magically' appears before your 
> CLASSPATH which
> can also confuse users when older versions of .jars are in there.
> 
> In the XML processing world, there are a number of bits of common
> standards-based code, including the following three 
> significant standards:
> 
> -- org.w3c.dom.* pacakges: DOM (Document Object Model) 
> interfaces and API
> definitions.
> Copies of these are currently included in most Xalan, Xerces, 
> and Crimson
> packages, and probably in various other packages.  Various XML
> parsers include their own implementations for the DOM classes.  
> Currently come in
> various flavors, including Level1 (outdated), Level2-working 
> draft (may
> people have these in their environment) and Level2-final draft
> (what Xalan-J 2.0.x expects).  Level3 is in the works.
> Xalan-J 2.x includes a copy of the Level2 source in it's CVS tree,
> and includes the .classfiles in xalan.jar  I think Xerces also 
> includes similar
> DOM files.
> http://www.w3.org/DOM/
> 
> -- org.xml.sax.* pacakges: SAX (Simple Api for Xml 
> processing) interfaces
> and API definitions.
> Copies of these are currently included in most Xalan, Xerces, 
> and Crimson
> packages, and probably in various other packages.  Various XML
> parsers include their own implementations for the SAX classes.  
> Currently come in
> various flavors, including 1.0 (older, but still in use), and 
> 2.0 (which
> Xalan-J 2.0.x attempts to use if it's available).
> Xalan-J 2.x includes a copy of the 2.0 source in it's CVS tree, and
> includes the .classfiles in xalan.jar  I think Xerces also 
> includes similar
> SAX files.
> http://megginson.com/SAX/
> 
> -- javax.xml.parsers, javax.xml.transform: JAXP, parts of 
> which used to be
> called TrAX; this is the product of the JCP's JSR-63
> This is an abstraction layer on top of both the XML parsing and
> transforming process, allowing you to plug-and-play XML 
> parsers and XSLT
> processors.  (JAXP 1.0 was only javax.xml.parsers; JAXP 1.1 added
> javax.xml.transform).  Xalan-J 2.x ships with a full copy of 
> the JAXP 1.1
> files and requires this version to work properly.  Xerces 
> ships with just
> the javax.xml.parsers half of JAXP 1.1.  Sun ships the 'reference
> implementation' distribution of JAXP 1.1 from their website, 
> which includes
> custom versions of xalan.jar and crimson.jar, along with a
> *separate* jaxp.jar
> http://java.sun.com/xml/
> 
> I'm sure that many servlet engines, webservers, JDK versions, 
> and other
> products also ship their own private copies of many of these 
> files. (We
> know Tomcat does, since it's been a FAQ and been answered here
> before)  
> 
> OK, for anyone who's still here: the upshot is that since 
> many independent
> products ship their own versions of these standards-based 
> files, that we
> can get into version mismatch problems when we include our 
> own versions of
> these standards-based files in our Xalan releases.
> 
> What's the right thing to do moving forward?  Work with the larger
> community (both xml.apache.org and other software vendors) to 
> improve the
> versioning and configuration of their products.  Many of the Xalan
> committers are thinking about this, although I'm not sure 
> what the best
> short-term solution is: we want to allow advanced users to 
> mix and match
> their standards-based files, but we want basic users to simply drop
> xalan.jar into their environment and have it work.
> 
> Hope that helped some, I'm not sure if I'm actually more 
> confused now or
> not!
> - Shane
> 

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOr+JM9UPOr8a7vy5EQKIvwCg5ZvS0MfcBASGmaX7OOdh1M/eYUsAoI0H
YnNtFMTJqe5jXIL2CHucluhl
=zkiK
-----END PGP SIGNATURE-----