Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XOM status

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: "Steve Loughran" <steve.loughran AT gmail.com>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] XOM status
  • Date: Fri, 7 Jul 2006 14:18:23 +0100

On 07/07/06, Elliotte Harold <elharo AT metalab.unc.edu> wrote:
Just a quick note to keep people abreast of what's happening.

At this point, I feel like XOM 1.2 is pretty much done code wise. I
don't foresee any other bug fixes, optimizations, or new methods. This
will actually be a fairly minor release compared to 1.1. Yes, there are
still optimizations I need to investigate and implement; but I don't
want to hold up 1.2 while I do that. Since they're not externally
visible, additional optimizations can always be done in a 1.2.1.

I am, however, a little blocked by Jaxen. As you may or may not know the
Codehaus servers that host Jaxen crashed majorly a couple of months ago.
backups were not up to date. That's all been recovered from by now and
no Jaxen work was lost. However as a result of that CVS access to Jaxen
has been disabled. What we have now non-anonymous Subversion access.

XOM's Ant build file actually tries to check the latest Jaxen code
straight out of CVS. This now fails. For those of you who watch Gump,
this is why Gump is failing XOM daily.

Gump has been suffering from a big sourceforge outage and a rename of
all the anon cvs hosts there, plus ongoing stability. Xoms failing has
been less noticeable, except for us downstream.

Now, if gump had anon SVN access, they could do a fetch and build
themselves. xom's build,xml would just have to check for the jaxen
stuff on the classpath and skip the jaxen fetch if it is already
there.


What I need to do is make a JAR of the relevant Jaxen code just for use
with XOM, and check that into XOM's own CVS. None of this will affect
the end product, just the build process. This is probably a good thing,
on its own. Even if Jaxen CVS were working, the way XOM was built was a
little flaky. Changes in Jaxen could change XOM from day to day even if
nothing else had changed.

Is this going to be a fork, or just a snapshot?


Ideally I'd like to be able to build XOM 1.2 against an official release
of Jaxen, specifically 1.1. That makes it easier to track bugs and build
the whole package. Fortunately, Jaxen 1.1 is very close. I and several
other people have now closed all but one of the known remaining issues
before Jaxen 1.1 can be released. The last issue is just documentation,
and if nobody fixes it soon; I may argue for releasing 1.1 anyway.


a full jaxen 1.1 release would be very good.

Thanks for the status update; gump has been failing on my
xom-dependent code for a while, now I know why.

-steve




Archive powered by MHonArc 2.6.24.

Top of Page