This is still too confusing. Why don't all XML-related Java projects agree to use a single, common JAR file that contains the various XML interfaces?
On Tue, 2003-01-14 at 17:18, [EMAIL PROTECTED] wrote: > 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] -- Slava Pestov <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
