Re: [xerces2] info about some packaging changes
A SAX-only jar would be feasable, at any rate. I have built a smaller jar that contains mostly SAX stuff from the build/classes directory, but I know that I included too much. We use Xerces as the main parser for several things, but its enormous monolithic size precludes us from using it in others. Various footprints for different uses was the feature we were anticipating most in X2. Bob Jamison LinCom Corp - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [xerces2] info about some packaging changes
- Original Message - From: Bob Jamison [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, December 02, 2001 3:46 AM Subject: Re: [xerces2] info about some packaging changes A SAX-only jar would be feasable, at any rate. I have built a smaller jar that contains mostly SAX stuff from the build/classes directory, but I know that I included too much. We use Xerces as the main parser for several things, but its enormous monolithic size precludes us from using it in others. Various footprints for different uses was the feature we were anticipating most in X2. Bob Jamison LinCom Corp - 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]
RE: [xerces2] info about some packaging changes
Hi: I created a DOM tree based a given xml file. I'm trying to make a copy of it, so I modify the copy without changing the original DOM tree. Could you please let me know how to do it if you get any idea? Thanks a lot. Jun -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, November 26, 2001 11:39 AM To: [EMAIL PROTECTED] Subject: Re: [xerces2] info about some packaging changes Ah, my confusion then! In that case (Xerces is doing a new xmlParserAPIs.jar) my vote doesn't even count, since I was indeed specifically talking about xml-apis.jar. On a quick read, sure, whatever Xerces wants to do like that is fine. Longer term, perhaps after we have our next major Xalan 2.2 release (which uses the new packaging) and we get more feedback, I'll have more comments. I think the larger issue of xml-related standards packaging (read: across all xml.apache.org projects, and across other software users that interact with Apache projects) will take time and a couple of iterations to work on. Um, I might just opt for an all lower case name, xml-parser-apis.jar instead. It's a little cumbersome, but is nicely descriptive. Hey, any release notes you can provide on where this will differ from an xml-commons produced xml-apis.jar (like omitting javax.xml.transform, and any other bugfixes you might make) would be useful too. - Shane you [EMAIL PROTECTED] wrote 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? :-) - 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]
Re: [xerces2] info about some packaging changes
[EMAIL PROTECTED] wrote: [snip] 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. I think there are some more involved issue here. JAXP APIs involve both a parser and XSLT processor so there needs to be some coordination between projects which may be difficult to achieve so that a single xml-apis.jar file from xml-commons can be produced. As it is now, it looks like Xalan has an xml-apis.jar file but it only contains the javax.xml.transform classes. Also, there are issues w/ which version of the standard to include in xml-apis.jar. I posted some emails on this on xerces-j-dev recently and about whether to support the latest versions of standards or some people want ones that are J2EE 1.3 compatible, for example. I don't have any answers, though. -Edwin - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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-generalm=100645101418438w=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]
Re: [xerces2] info about some packaging changes
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-generalm=100645101418438w=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]
Re: [xerces2] info about some packaging changes
Ah, my confusion then! In that case (Xerces is doing a new xmlParserAPIs.jar) my vote doesn't even count, since I was indeed specifically talking about xml-apis.jar. On a quick read, sure, whatever Xerces wants to do like that is fine. Longer term, perhaps after we have our next major Xalan 2.2 release (which uses the new packaging) and we get more feedback, I'll have more comments. I think the larger issue of xml-related standards packaging (read: across all xml.apache.org projects, and across other software users that interact with Apache projects) will take time and a couple of iterations to work on. Um, I might just opt for an all lower case name, xml-parser-apis.jar instead. It's a little cumbersome, but is nicely descriptive. Hey, any release notes you can provide on where this will differ from an xml-commons produced xml-apis.jar (like omitting javax.xml.transform, and any other bugfixes you might make) would be useful too. - Shane you [EMAIL PROTECTED] wrote 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? :-) - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [xerces2] info about some packaging changes
since reorganizing the DOM seems to be needed anyway, we thought it might also be a good time to follow Xalan's lead and split the API's we support and the implementation of those API's into separate jar files. 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. We also plan to keep our API's in our own CVS repository, periodically checking to make sure they're in sync with xml-commons. We don't want to use xml-commons so that we can move quickly on API updates--such as when DOM level 3 becomes a full-fledged recommendation. The advantage for users of this API split is that it could save them some space: If you want to use Xerces and Xalan together, then you only need to include one API jar file on your classpath to make everything work. This means your xerces jarfile will be about 7% smaller than it would be if it contained API's as well as implementations. could there be an advantage to splitting xml-apis.jar out into finer components, ie xml-apis-dom3.jar + xerces-dev wont need their own copy of the rest xml-commons, and avoid the sync issue for that. + xerces-dev might have more freedom to update it in xml-commons more readily, or at least make syncing from their copy easier. this might be particular to dom3, until it becomes a full-fledged recommendation, or all recommendations could have their own jar, reducing bloat in xml-apis.jar over time + possible(?) space savings for all projects. eg, if dom1 is never used in a particular project, its xml-apis-dom1.jar is not included or those concerned about names: we thought we'd call the new implementation-specific jarfile xercesImpl.jar, so as to distinguish it from the xerces.jar that contains everything. The API file we thought could be called xmlParserAPIs.jar, since it contains only API's related to XML parsing. at any rate, naming it xml-apis-dom3.jar within xerces might make it more obvious where it is going to end up. - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
