Hi Ben, I'd actually thought of making ant targets to build different flavours of API files along these lines. A couple of things to be aware of though:
If you want SAX and you want schema, then you'll still need DOM API's with xerces (1 or 2) because we use them internally to parse schema documents. If you want DOM, then until DOM level 3 becomes standardized you'll need SAX because that's how Xerces (1 or 2 again) reports errors and handles entity resolution. So it seems to make sense at the moment to keep all the API's in one place for now by default. But if there's enough demand (or, better yet, a patch!) it would be easy to build API-specific jars. On the issue of sync'ing up with what's in xml-commons: the other nice thing about having our own CVS copies of everything needed by the project is that it makes bootstrapping for new developers easier. Also, if we have to sync periodically, it gives us a second chance to check our stuff against what's in commons and see what changes might have taken place there--since, in general, I don't think most of the Xerces folks would have time to follow commons in as much detail as our own project. And this certainly doesn't preclude us from getting fixes applied to commons in a timely manner, if we make sure we do a sync before each new Xerces release. So it's not an ideal solution but it's not all bad either. Cheers, Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] Ben Coman <[EMAIL PROTECTED]>@aurema.com on 11/22/2001 06:33:20 PM Please respond to [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: 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] --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
