[EMAIL PROTECTED] wrote:
>
> 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.
Yes, I fully agree.
> 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?
Yes, that is a good summary. BTW, I meant to post a summary on
general@xml, but have not done it yet. In my numbering scheme, though,
solution #2 and #3 are swapped.
>
> 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.
Yes. The proposal is to eliminate duplicate copies of source code in
multiple trees (and branches) and instead obtain the source from
xml-commons. Everything else would remain the same. So creating the
binary distribution would reference source from xml-commons, but
creating the source distribution would copy the source from xml-commons.
>
> 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?
I have not thought about this. In my crimson prototype, the build.xml
file looks for a peer xml-commons tree. If it does not find one, it
prints an error message to the user.
>
> 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?
My prototype did not provide a way of building the source distribution
itself, but this seems desireable. In effect you want two targets, A)
one that builds the files from a source distribution and B) another that
creates the source distribution itself. Target B would have to know how
to reference souce files from xml-commons but target A uses the source
files from the source distribution itself. One thought is that you
could combine the targets into C) which would do the equivalent of the
following in Ant:
if (part of source distribution) then
build from source already present in distribution
else
build from source from xml-commons
endif
As a first step, I would get this working with the javax.xml.* source
code as the version that is in the xml-xerces repository now is quite
old and buggy.
-Edwin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
