XOM API for Processing XML with Java

[Tatu Saloranta <cowtowncoder AT yahoo.com>]

--- On Thu, 1/8/09, Elliotte Harold <elharo AT metalab.unc.edu> wrote:

...
> > Hi everyone, I'm aware this same question was asked before here
> https://lists.ibiblio.org/sympa/arc/xom-interest/2006-July/003075.html but 
> it
> > seems it wasn't answered (or at least I can't find the answer anywhere)
> > I'm having exactly the same problem, and not only with version 1.2 but 
> > with
> > version 1.1 too. Also, can anyone explain why XOM insists in compiling the
> > Jaxen sources when just including the jar in the classpath would suffice?
> 
> Because classpaths are a royal pain to deal with. I want XOM to require 
> nothing more than a standard VM to run.

This is understandable.
But going forward, one potential solution to this might be using OSGi: they 
handle this problem quite nicely, I think, and it is relatively easy to 
"convert" existing libraries to have necessary OSGi information.
When running on OSGi platform, different libraries can depend on different 
versions of other libs (defined by versions that relate to Java packages, not 
jars).

So, would it make sense to start adding OSGi information within XOM library.  
This requires nothing more than adding proper manifest entries and testing 
result loads with, say, Felix console. There are Ant and Maven tasks for 
doing this. For things to work, same would also need to be done for Jaxen 
(which should be easy too).
Since this only solves the problem for OSGi users (code running on systems 
that use OSGi for class loading) it would mean having to provide 2 versions 
of XOM -- one with bundled Jaxen, other without (latter using OSGi), at least 
on short/medium term.
But I think this could still be worth the hassle.

What do you think? I could help with OSGi bundle building if necessary.

-+ Tatu +-