xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ne...@ca.ibm.com
Subject Re: [xerces2] info about some packaging changes
Date Fri, 23 Nov 2001 14:39:22 GMT
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.

Neil Graham
XML Parser Development
IBM Toronto Lab
Phone:  905-413-3519, T/L 969-3519
E-mail:  neilg@ca.ibm.com

Ben Coman <benc@sw.oz.au>@aurema.com on 11/22/2001 06:33:20 PM

Please respond to general@xml.apache.org

Sent by:  benc@aurema.com

To:   general@xml.apache.org
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:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message