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]
