Hi Joseph, >Trying it that way now, using our PARSER_JAR environment variable to override and point to both the new jars instead of the old one .
You should not need both jar files. Could you try it again eliminating xmlParserAPIs.jar from your classpath? Since Our API support and yours are almost completely in sync now, this should not cause your problems; here's hoping it fixes the non-compatibility issue. >I had to recompile Xalan from scratch, which is going to be a maintainance/distribution problem unless it can be corrected -- it would force us to ship two different ready-to-run builds, which I don't think we'd be happy with. Clearly. And it's very largely for Xalan's benefit that we did the jarfile split in the first place. If you're not able to capitalize on it by not including the API jarfile, perhaps we'll want to revisit the split itself for the production release. >General comment: Factoring out the standards is a fine idea -- Xalan also did so, with its xml-apis.jar file -- but unless Apache can reach a consensus on a _common_ factoring, the idea simply does not achieve its goals. But the factoring has to depend on the characteristics of the product being factored. We just don't support javax.xml.transform stuff, so why would we distribute it? This is the only reason we call our API jar something different than you call yours; but ours should be as close to a proper subset of yours as different source repositories will allow. >I'm not saying that xml-apis.jar is necessarily right and xmlParserAPIs.jar is necessarily wrong, but the two should agree on what is and isn't an XML API and have, at worst, equivalent content. (I would really like to see a _single_ xml APIs jarfile for all of Apache, to guarantee we're all speaking the same language -- with local overrides if necessary for prototype APIs, which could be placed earlier on the classpath if and only if there's an intent to use the prototypes.) Even for products which don't support all API's? Perhaps a better solution would be to have some sort of lowest common denominator API jar (perhaps even xmlParserAPIs.jar) that all products will either implement or rely upon, and split other API content into jarfiles that can then be shipped by the particular products that implement them? Cheers, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
