Hi Edwin,
I've also been following the discussions on general on this topic. While I
think I agree with your proposal in principle, for the benefit of those who
don't follow general all that closely perhaps we should give people a bit
of time to consider the issues before rushing ahead to solve them.
To summarize: xml.apache.org has a problem in that several projects
contain common interfaces--DOM, SAX and JAXP. Unfortunately, they're not
necessarily all exactly the same version: we have a couple of DOM l3
methods in our org.w3c.dom, Xalan doesn't. This creates some interesting
issues for users of xml.apache.org projects relating to classpath ordering
etc.
There's also the simple matter of space: Why should exactly the same code
be duplicated in many places when the xml-commons project was founded
precisely to store common API code?
So Edwin proposed three solutions on general:
1. Do like we do now--every project has its own API source--but, wherever
possible, get it from xml-commons.
2. Use the xml-apis.jar that can be built by the ant script in
xml-commons.
3. Have many little API jarfiles: a DOM2.jar, a DOM3.jar, a SAX.jar, etc.
The former option is the simplest for us developers, and eliminates the
problem of long classpaths for users. option 2 poses problems for projects
like us which do our own thing to some degree with evolving API's. #3
risks confusing both users and developers in an alphabet soup of jarfiles.
#1 seemed to get the most support.
Edwin, is that a decent summary?
Anyway, I have some specific questions about your proposal:
1. Will the source package which our ant build generates contain the JAXP
API? I for one think it should, just as the binary package must contain
the classes.
2. How does the user specify where xml-commons has been checked out on his
local file system? Some folks use "co -d" to override the default
directory structure; how do we account for this?
3. Related to 1. and 2. above, how does the build.xml that we ship in our
source distribution know that it already has the JAXP files, whereas the
build.xml file that we check out of CVS knows that it has to go and find
them?
Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 416-448-3519, T/L 778-3519
E-mail: [EMAIL PROTECTED]
Edwin Goei <[EMAIL PROTECTED]> on 09/24/2001 04:56:03 PM
Please respond to [EMAIL PROTECTED]
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
cc: Elena Litani/Toronto/IBM@IBMCA
Subject: Copying source from xml-commons
There is code in Xerces 1 and 2 as well as other projects (Xalan) which
is obsolete and has bugs such as this one:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2298. (Thanks Elena
for forwarding the bug to me.) The fix is to use the latest versions of
code for the javax.xml.* packages. That code exists in the
"xml-commons" repository under java/external.
The cleanest way to fix this and other bugs like it is to remove the
copies from xml-xerces and instead copy source code from xml-commons
during the build process of Xerces. This would mean that developers
would need to have two parallel trees checked out to do a build:
xml-xerces and xml-commons.
BTW, I have already prototyped this using the Crimson build. Ideally,
we would want to copy not only the javax.xml.* packages, but also the
DOM and SAX packages, but we can start with just the javax.xml.*
packages. (I think there was some DOM L3 prototyping work going on.)
I'll volunteer to make changes to the Ant build.xml file if this is OK
with everyone. Comments?
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
