Hi Shane, Your points are perfectly valid, and that's precisely why I proposed *not* to call the API jar file "xml-apis.jar". It just contains parser API's, so let's call it something like xmlParserAPIs.jar. (Any better suggestions?)
Do you think this will remedy the confusion you rightly believe would result from our usurping the xml-apis.jar name? Does it change your opinion of the proposal? :-) And finally: a big +1 to some help with manifest files! Cheers, Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] Shane Curcuru/CAM/Lotus@Lotus on 11/26/2001 10:52:17 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: [xerces2] info about some packaging changes ---- you [EMAIL PROTECTED] wrote ---- > We're planning to keep the API jar as close > to the xml-apis.jar that xml-commons produces as possible, but > obviously we won't be shipping the javax.xml.transform packages, > since we don't implement these interfaces. Here's my: -1 vote to Xerces' xml-apis.jar not including the java.xml.transform package. (Of course if I'm pretending to 'vote' on the issue, I should really be on xerces-j-dev, but this is a larger cross-project issue) While Xerces won't provide an implementation of a transformer, this packaging will result in confusion for users who think that the xml-apis.jar in Xerces builds is roughly compatible with the one from Xalan builds - if you exclude the javax.xml.transform packages, it's completely different. While I understand (and am doing for the time being, in Xalan) the separation of building xml-apis.jar for a project directly from it's own source tree instead of from the xml-commons source tree, I think we should all strive to keep the contents of the jar file named 'xml-apis.jar' to be roughly equivalent. 'Roughly' meaning that the jar should always include the *full* sets of SAX 2.0.x files, DOM L2 files, and JAXP 1.1.x files. I.e. to me the point is that we're agreeing to ship *stable* externally-defined standards-based files in a jar named xml-apis.jar. Any other files a project wants to use should go in their implementation jar, or somewhere else; and the xml-apis.jar should always include it's full contents, and should match very closely (except for last-minute bugfixes) the same code as in xml-commons. Am I making any sense? Does anyone else agree with me? (Note, they're separate questions!) One other important issue is we should have some manifest packaging expert help us all implement some better documented and finely-grained versioning info in our manifests; I've started in xml-xalan/java/src/MANIFEST.MF but it needs updating and I'm not sure I've gotten it quite right yet. - Shane (View the start of Neil's thread: http://marc.theaimsgroup.com/?l=xml-apache-general&m=100645101418438&w=2 with followups to general@xml and xerces-j-dev) --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
