xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edwin Goei <edwi...@sun.com>
Subject Re: xml-commons XML API and API evolution
Date Tue, 21 Aug 2001 01:15:26 GMT
Shane_Curcuru@lotus.com wrote:
> My first thought: have each project import only the specific *sources* they
> need, and compile them into the .jar.  This way we only have one copy of
> the sources, but no need for an extra xml-apis.jar; each project will
> include the minimum compiled .classes that they need to run.

Yes, this is what I am proposing.  During the build process, the sources
would be copied from xml-commons as part of the build process of a
project such as xalan or xerces.  The binaries: xalan.jar, xerces.jar,
crimson.jar, etc. would contain the compiled versions of the class files
generated from the common source.

> For this,
> there are important working questions, like:
> -- do the projects copy in the sources and leave them hanging around (and
> thus leave them in the src dir of the distro) or do they simply refer to
> them, or refer to a build target, in the local xml-commons repository?

This is somewhat of a separate issue, but I would include the copied
source into the source distribution.  For example, crimson only
implements DOM L2 Core and so only needs to copy those classes from
xml-commons.  Only those classes would be included in crimson.jar and
only those classes would be included in the source distribution.  Xerces
implements other DOM sub-packages so for that parser, more source and
binary would be correspondingly included.

> Another big question is: how do we present this (i.e. document) for
> multiple xml projects? We want to be sure that users and developers alike
> can easily use and compile each project, even when they want to mix
> projects or have both cocoon, xalan, and crimon on their disk at the same
> time.  Each project needs to be careful to include the common code they do
> need, but hopefully not include anything extra to avoid duplication.

In a similar way, I would say that each project includes docs for what
they implement.  For example, crimson will only document DOM L2 Core and
Xerces would also document DOM L2 Range and Traversal, etc.

> Another issue: how do we deal with versioning?  I'm not as concerned yet
> with DOM L3 (since I think they explicitly have ways to do this, like using
> separately named rangex packages for new L3 classes until their finalized)
> but more with Xalan/Xerces/Cocoon/etc versions, and JAXP versions.  I.e.
> what if a user really wants to use the current Xalan with new JAXP stuff,
> but with the old Xerces?

I'll comment on this in a reply to another email.

> Hmmm.  Needs more thought, I'm just starting to ramble.  Thanks for
> starting the conversation: I was just about to add an experimental option
> to the xalan build.xml to pull in the xml-commons code!

I've already been prototyping such a build for crimson which is the
reason I restarted this thread.


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