DO NOT REPLY [Bug 3814] - Poorly packaged xalan.jar

[bu...@apache.org]

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=3814>.
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=3814

Poorly packaged xalan.jar

curcuru@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From curcuru@apache.org  2001-10-03 08:43 -------
> 1. A stripped down version of the Sun JAXP interfaces are included in the
> xalan.jar file. 
This is a design decision that's partly historical and partly a wish of many of 
our committers.  Having the transform-half of JAXP inside our jar makes it 
easier for many end users to use xalan - all they need is our .jar and a 
parser's jar.  It's also easier to recompile us out-of-the-box.  Although we 
(well, I am at least) very happy to be chosen as the reference implementation 
of the most recent JAXP spec, Xalan is also it's own project with a wide 
variety of users, some of whom don't even use the JAXP calls.

> 2. The xalan.jar file's manifest includes two XML parsers in its classpath:
> xerces and crimson. This is surely an error, as only one can be active.
> Actually, neither should be referenced, as the documentation states that xalan
> is parser implementation neutral (except that old xerces versions don't work).
Again, a design decision to make it easier for users.  Re: implementation 
neutral - we are, as long as the parser supports JAXP.  We rely on the JAXP 
parser finding code, so if there are issues with that, you should work with the 
JAXP team.  Having the jars listed there is not a hard dependency, it only 
shows that if the choice is left up to our .jar file, we'd prefer one of those 
parsers (the user is always free to override in one of several ways).  I was 
confused by having both parsers referenced, but if there are still questions 
about that, you can ask Costin on the xalan-dev list.
For more info on the JAXP 'Plugability Layer', see section 3 of 
http://java.sun.com/xml/jaxp-1_1-spec.pdf

> 3. Can you start putting in Implementation-Version tags into the manifest?
Already done in D11.  If anyone has specific questions or suggestions as to how 
to implement these, let us know on xalan-dev (I just split it into the main 
package groups in Xalan)

> 4. Why is the xml.jar file included in the distribution?
http://xml.apache.org/xalan-j/xsltc_usage.html#classpath
You now get two XSLT processors for the price of one!  The xml.jar is 
supporting classes needed by the xsltc processor, now included as an alternate 
implementation of the JAXP transform stuff.  Future plans call for some code 
merges between xalan and xsltc which will (hopefully) get rid of all these 
extra .jars, but that will take a while.