XOM API for Processing XML with Java

[Michael Kay <mike AT saxonica.com>]

This seems to ignore the fact that the versions of Xalan and Xerces 
included in the Sun JDK 1.5 and 1.6 distributions have serious bugs, 
which no-one seems to be interested in fixing, and no-one should be 
using these versions in preference to the Apache distributions.

Michael Kay
Saxonica

On 29/09/2010 11:25 AM, Dmitry Katsubo wrote:
> Dear XOM community,
>
> I think the developers should decide what JDK XOM is targeting. I hope
> the majority of Java world uses Java 1.5 or higher, which has most of
> dependencies below included. So most of us will have classpath problems,
> clashes and unexpected behavior when using XOM as it is now. The
> dependencies' tree for v1.1 is:
>
> xom:xom:jar:1.1:compile
> +- xerces:xmlParserAPIs:jar:2.6.2:compile
> +- xerces:xercesImpl:jar:2.6.2:compile
> +- xalan:xalan:jar:2.7.0:compile
> \- jaxen:jaxen:jar:1.1-beta-8:compile
>     \- jdom:jdom:jar:1.0:compile
>
> XOM itself is very compact, but with all dependencies it is not. Of
> course, one can use Maven exclude dependency feature, but it is sad to
> see that in 100% of XOM use cases in Maven2 one needs to exclude all
> unnecessary staff.
>
> I agree with Adam Constabaris [1] Cédric Champeau [2] that something
> needs to be improved with respect to dependencies. xerces:xercesImpl and
> xalan:xalan should be to my opinion "runtime" "optional" dependencies
> and xerces:xmlParserAPIs (was replaced with xml-apis:xml-apis:1.3.03 in
> most recent 1.2.5 release) should be "compile" "optional" dependency.
>
> Also needless to note that jaxen:jaxen is real compile-time dependency
> for XOM at the moment, as there are references from nu.xom.XPathContext
> and nu.xom.Node. The last dependency is crucial: one cannot load the
> Node class without having Jaxen in classpath (fix me if I am wrong),
> which makes Jaxen non-optional dependency. The XPath infrastructure
> should be refactored in a way that Jaxen becomes an "compile" "optional"
> dependency. The example of good dependency management is dom4j [4].
>
> Jaxen is not perfect as well. If you link against the latest
> jaxen:jaxen:1.1, you will get jdom and dom4j as dependencies. All
> together three (!) XML frameworks in one bundle.
>
> My opinion about backward compatibility: you cannot solve it with the
> help of "classifiers", as classifiers do not have dedicated pom files,
> thus you cannot determine different dependencies for different
> classified jars. As it usually done: starting from some version of the
> library the JDK compatibility is defined. Say, from XOM v2.0 the
> supported JDK is 1.4.2 or higher. In parallel v1.0 supports (for
> example) Java 1.2 or higher, and further bugfixes should be released as
> v1.0.1, v1.0.2 etc. It needs branching and a bit maintenance, but it is
> worse efforts.
>
> > [1] https://lists.ibiblio.org/sympa/arc/xom-interest/2005-December/002730.html
> > [2] https://lists.ibiblio.org/sympa/arc/xom-interest/2009-March/003869.html
> > [3] https://lists.ibiblio.org/sympa/arc/xom-interest/2005-January/001837.html
> > [4] http://repo1.maven.org/maven2/dom4j/dom4j/1.6.1/dom4j-1.6.1.pom