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

[Sh...@lotus.com]

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