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 Mon, 26 Nov 2001 15:59:41 GMT
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:  neilg@ca.ibm.com



Shane Curcuru/CAM/Lotus@Lotus on 11/26/2001 10:52:17 AM

Please respond to general@xml.apache.org

To:   general@xml.apache.org
cc:
Subject:  Re: [xerces2] info about some packaging changes


---- you neilg@ca.ibm.com 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:     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


Mime
View raw message