Dmitry Katsubo
2010-09-29 10:25:40 UTC
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.
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] http://lists.ibiblio.org/pipermail/xom-interest/2005-December/002730.html
[2] http://lists.ibiblio.org/pipermail/xom-interest/2009-March/003869.html
[3] http://lists.ibiblio.org/pipermail/xom-interest/2005-January/001837.html
[4] http://repo1.maven.org/maven2/dom4j/dom4j/1.6.1/dom4j-1.6.1.pom
[2] http://lists.ibiblio.org/pipermail/xom-interest/2009-March/003869.html
[3] http://lists.ibiblio.org/pipermail/xom-interest/2005-January/001837.html
[4] http://repo1.maven.org/maven2/dom4j/dom4j/1.6.1/dom4j-1.6.1.pom
--
With best regards,
Dmitry
With best regards,
Dmitry