Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Why is xom 1.1 only using parts of jaxen?

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Harold <elharo AT metalab.unc.edu>
  • To: Michael Kay <mike AT saxonica.com>
  • Cc: 'Manfred Nysted Berry' <Manfred.Berry AT fast.no>, xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Why is xom 1.1 only using parts of jaxen?
  • Date: Thu, 13 Jul 2006 11:15:38 -0400

Michael Kay wrote:
This does look like a potential source of integration nightmares, for
example if someone has an application that uses XOM for one of its input
files and also uses some other product that uses Jaxen. If XOM is to ship a
subset of Jaxen, it would be better to change the package names.


XOM does not advertise that it bundles Jaxen, except in so far as due credit requires. Furthermore it makes no promises that it will continue to bundle Jaxen in any particular release in the future. I've designed XOM's XPath API such that the Jaxen dependence is invisible, can be swapped out fairly easily, and may be in the future. This contrasts with, for example, the dom4j and JDOM XPath APIs which are publicly tied to Jaxen.

There are at least two other XPath implementations I have considered using (Saxon is one) and I may revisit my choice at a later date, even in a minor release. Anyone relying on XOM to supply Jaxen for their project is building on sand.

What's in XOM are the actual unmodified Jaxen classes. If you're writing code that uses Jaxen APIs, adding full Jaxen to your classpath should cause no conflicts.

--
Elliotte Rusty Harold elharo AT metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/




Archive powered by MHonArc 2.6.24.

Top of Page