Hi all,
Though I don't think there's been any public feedback to this query, I've
had a couple of private responses. Based on this feedback, here's what I
plan to do; I'll make the changes on Friday if I hear no objection.
1. Remove all files in our CVS repository from the following packages,
except for org/w3c/dom/html/HTMLDOMImplementation.java, which is unique to
Xerces.
- org/xml/sax/(*,ext/*,helpers/*)
- org/w3c/dom/(*,events/*,html/*,ranges/*,traversal/*)
- javax/xml/parsers/*
2. Update the xml-apis.jar we currently have in CVS so that it reflects
the current state of the TCK-compliant branch of commons;
3. Add a copy of the xml-apis--src.tar.gz from the TCK-compliant branch of
xml-commons into our tools directory;
4. Cleverly modify our binary distribution target so that:
- xml-apis.jar is copied into our binary distribution,
- xmlParserAPIs.jar is created by copying xml-apis.jar to a file by
that name,
- the commons sources are used to create appropriate javadocs for the
interfaces we support (that is, javax.xml.parsers, org.w3c.dom,
org.w3c.dom.(events, html, ranges, traversal), and org.xml.sax.*;
5. Modify the source target so that it contains sources for the API's that
we support (as in 4. above);
6. Modify the tools target so that it contains a copy of
xml-apis--src.tar.gz.
How does that sound to people? Have I forgotten anything?
Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
----- Forwarded by Neil Graham/Toronto/IBM on 01/14/2003 05:18 PM -----
|---------+---------------------------->
| | Neil Graham |
| | |
| | 01/03/2003 05:26 |
| | PM |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| From: Neil Graham/Toronto/IBM@IBMCA
|
| Subject: leveraging commons code
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
Hi all,
Here's Hoping that everyone enjoyed the holidays! Dunno about anyone else,
but they certainly seem to me to have passed by very quickly....
Anyway: for quite a while many folks in this and the broader Apache
community have been mulling how to keep related projects in lock-step viz.
the API's they rely upon. This was the idea behind xml-commons and our API
vs. implementation jar split, and it's one that's supported by many
spurious bug reports having to do with idiosyncratic (or even
not-so-idiosyncratic) user classpath settings.
At long last, there exists a branch (tck-jaxp-1_2_0) in xml-commons that
contains a set of API's that are compatible (that is, JAXP 1.2
TCK-compliant) with those we currently carry in our CVS tree. It seems
that there will be a commons release soon that contains the product of this
branch, and I have it that Xalan is planning to pick the product of this
release up and incorporate it in its codebase.
For stable API's that we are currently required to implement completely
(that is, SAX 2.0, DOM core level 2, and JAXP 1.2), it seems to make
overwhelming sense that we figure out how to leverage this code directly
rather than continuing to maintain an entirely separate repository. This
way, we and Xalan--and any other Apache projects that are required to
implement these API's without any deviations--are guaranteed to be on
precisely the same page with respect to API's, and will all move forward
together as the pertinent standards evolve.
The trouble is it's not entirely obvious how to do this and remain true to
the philosophy that has led us to insist on building against API source and
distribute precisely those API's that we implement. I can see 4 options:
1. Do what Xalan does: take a copy of xml-apis.jar from commons, put it
in our tools directly, and treat it in the same way we treat the rest of
our tools.
2. Go part of the way towards Xalan: implement a new build target in this
branch of commons that constructs our familiar xmlParserAPIs.jar, put it
somewhere and compile against it.
3. Do something vaguely like what we do now: implement a new build target
in the new branch of commons that tars (or zips) up the source files we
need for our xmlParserAPIs.jar, put that tarball somewhere and modify our
build scripts to untar it so that we can compile against it and produce
xmlParserAPIs.jar.
4. Do something much like we do now: Implement a CVS task that extracts
the relevant portions of the relevant branch of commons whenever we need
them. This has the drawback that it requires CVS to be implemented on the
platform we're being built upon; this might seem a bit of a strict
requirement for a project that distributes a tools distribution it's
supposed to be compiled with.
Assuming the present situation isn't tenable, these are all the options I
can think of for moving forward. At this moment I'd probably find option 3
most pallattable personally, but I'm hoping others might have better
ideas...
Thoughts?
Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
