XOM API for Processing XML with Java

[Cédric CHAMPEAU <cedric.champeau AT lingway.com>]

Hi,

First of all, I've really pleased to see there's a new release of XOM, 
since it's the most practical XML parsing library I've ever used in 
Java. I'd like to react about the Maven artifact introduction : I'd 
*really* like to see XOM in the Maven public repo. Currently, the 
central repository includes version 1.1 with groupId xom and artifactId 
xom. However, as Adam said, marking jaxen and xerces as dependencies is 
not a good idea. I think the best thing to do is to mark them as 
*optional* dependencies : that would cut transitive dependencies 
management without all the mess of classifiers. Finally, I think the 
"xom" groupId does not reflect the conventions (should be "nu.xom").

Please let me know if you decide to create and upload an artifact : it 
would avoid us to deploy xom on our internal repository.

>Count me as someone who thinks it would be useful to make XOM 1.2
>available through Maven (which also helps Ant/Ivy users).
>
>Realizing fully that what I'm about to say is not going to make it sound
>like I believe Maven/Ivy are useful in the end, I'll add a plea to
>consider how XOM specifies its dependencies before uploading a POM to
>Maven's central repo.  I'm willing to help with any of the specifics, if
>need be.
>
>XOM 1.1 specifies Jaxen as a dependency, which is true in one sense
>(XOM's XPath uses Jaxen code), but not in the Maven sense (since the XOM
>jar bundled the Jaxen classes).  This makes incorporating XOM 1.1 into
>one's applications harder than it needs to be, because Jaxen's
>transitive dependencies fan out over dom4j, xpp3, and all sorts of other
>stuff, so pulling in XOM pulls in 'competing' libraries you probably
>don't need or want.  This can be handled with Maven's exclusion
>mechanism, but it's still kind of painful.
>
>IIUC, in the Maven sense, XOM depends only on having one of its
>supported XML parsers (and, if you're using it for XSLT, an XSLT
>processor) on the classpath ; in practice, this means having a JRE that
>includes JAXP (JRE 1.4+) or the relevant parser (e.g. Xerces) jar.
>Since Elliotte wants to maintain (or, speaking strictly, advertises)
>compatibility all the way back to Java 1.0, this makes things a little
>more interesting.  Different environments will call for different POMs.
>
>If you want to support this backwards compatibility with Maven, you'll
>probably need to use "classifiers"; a classifier is an extra piece of
>metadata that lets you select an environment-specific version of a jar
>or its dependencies (e.g. xom-1.2-jdk13.jar could be byte-for byte
>identical with xom-1.2-jdk14.jar, but they'd have different POMs with
>different dependencies).
>
>Alternately you could bet that Maven users are likely to be working with
>JRE 1.4 and later, and ship a POM with no (or only optional)
>dependencies (and perhaps document that in the POM's description, just
>in case) ...
>
>cheers,
>
>AC