Discussions about packaging of xml-apis.jar should move to [EMAIL PROTECTED] or maybe [EMAIL PROTECTED], since 1) it's an xml-wide issue, not just a Xalan issue, and 2) the xml-commons project is where the original code lives. I plan to try to keep Xalan packaging as closely to the xml-commons project or the best concensus of the overall xml group when I can.
The issue of what to separate, which jars, what jar names has already been hashed out several times; the best consensus I could see was all stable, externally-defined standards-based code in a single jar, with a name of 'xml-apis.jar'; we even had a vote on it at one time. Xalan and Xerces just happen to be the first two groups using this new suggestion. Xerces is still catching up; specific questions about xerces packaging should go to a xerces list; however they'll probably note that older builds did their own thing (all files in xerces.jar); their current plan with recent builds is to use a very similar xml-apis.jar as Xalan and xml-commons, with special handling for DOM L3 methods that will be done. - Shane ---- you "Paul Brown" <[EMAIL PROTECTED]> wrote ---- I think that this is a good thing in general, but it can be a source of confusion and frustration. For example, the DOM API included with Xerces 1.4.4 has DOM3 experimental methods in the interfaces, so other applications won't necessarily build against it. If you're going to go with an unbundled strategy, then separate JARs for the different APIs would be nice: DOM2.jar, SAX2.jar, etc. It can make for a long classpath, but it's the clearest alternative. -- Paul
