leveraging commons code

[ne...@ca.ibm.com]

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



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org