>It looks like the compilation problems with Xalan2 and Xerces2 are resolved.
I checked in a change which allows Xalan-J to compile and run with Xerces2. We don't yet leverage Xerces2's built-in incremental parsing feature (XMLPullParserConfiguration), since I was having trouble finding a way to do that via reflection so we could continue to compile/run in the Xerces1 environment as well (and so a single compilation will run in both). Instead, we handle incremental for Xerces2 the same way we do other parsers, via our couroutine-based solution. I think I've now got a solution that will let us fully leverage both Xerces1 and Xerces2 from a single zipfile, but it's still under development and may not make it into D12. IN RELATED NEWS: xml-common's current implementation of org.apache.xalan.xslt.FactoryFinder does not compile under either IBM JDK 1.1.8 or MSVJ++. It has a hard compile-time dependency on getContextClassLoader, which simply isn't available in early dialects of Java. (I haven't tried it yet under Sun's 1.1.x JDK but I'd expect the same failure.) In past builds we used a reflection-based solution to avoid this problem. We should probably switch back to it if we intend to continue to support JDK 1.1 environments. Should I go ahead and try to check in a patch (if CVS lets me get away with it), or should I wait for someone who's officially on the xml-commons team to do so? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
