Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XOM, Maven and dependencies

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Michael Kay <mike AT saxonica.com>
  • To: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM, Maven and dependencies
  • Date: Wed, 29 Sep 2010 11:36:04 +0100


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





Archive powered by MHonArc 2.6.24.

Top of Page