using saxon within a mojo

[Gregory Kick <gk...@gmail.com>]

I'm writing a plugin that I would like to be able to use the saxon
XPath 2.0 implementation.  I've got it working perfectly fine in my
unit tests, but when I try to run it as a mojo, it reverts back to
using the jdk XPathFactory.  I would assume that this has something to
do with the whole META-INF/services mechanism being screwed up by
classworlds, and that's fine, but I couldn't get
MAVEN_OPTS=-Djavax.xml.xpath.XPathFactory=net.sf.saxon.xpath.XPathFactoryImpl
or even System.setProperty("javax.xml.xpath.XPathFactory",
"net.sf.saxon.xpath.XPathFactoryImpl") to work either.  (Not that I
really expected anything from System.setProperty()...)

Does anyone know how to either make maven respect META-INF/services or
set the system property and make it stick for mojos?

-- 
Gregory Kick
gk5885@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: using saxon within a mojo

[Aaron Digulla <di...@hepe.com>]

Quoting Gregory Kick <gk...@gmail.com>:

> I'm writing a plugin that I would like to be able to use the saxon
> XPath 2.0 implementation.  I've got it working perfectly fine in my
> unit tests, but when I try to run it as a mojo, it reverts back to
> using the jdk XPathFactory.  I would assume that this has something to
> do with the whole META-INF/services mechanism being screwed up by
> classworlds, and that's fine, but I couldn't get
> MAVEN_OPTS=-Djavax.xml.xpath.XPathFactory=net.sf.saxon.xpath.XPathFactoryImpl
> or even System.setProperty("javax.xml.xpath.XPathFactory",
> "net.sf.saxon.xpath.XPathFactoryImpl") to work either.  (Not that I
> really expected anything from System.setProperty()...)
>
> Does anyone know how to either make maven respect META-INF/services or
> set the system property and make it stick for mojos?

I had similar problems with SaxParserFactory. What happens is that the
JDK not only sets the default implementation but also remembers the
classloader to use to look for an implementation. After that, Maven is
loaded, sets its own classloader and when your mojo comes into view,
there is no way to revert the mistake the JDK made.

That's why MAVEN_OPTS doesn't work: When the JDK wants to load the
class, the mojo isn't there, yet, so the JAR hasn't been loaded by the
Maven classloader . When the mojo (and all its dependencies) have been
loaded by Maven, the JDK has already made up his mind that only his
own classloader could possible find these classes. Like in: "Nobody in
their right mind would ever try to install their own custom
classloader when using XML! That's ridiculous!"

Of course, all this is private/hidden/unaccessible/go-away-and-die, so
you can't hammer the right values back in. I've tried with
setPrivateField (using reflection and Field.setPrivate(false)) with
some success but you easily end up with a classloader mess (half of
the classes loaded by the wrong classloader) if you can't call this in
the right moment (basically, you have to do this *before* Maven
accesses the XML classes the first time ... like before it tries to
read pom.xml ... If you can show a way to do that from a mojo, you
might have found a way to travel backwards in time ;-))

The only stable solution I found so far was to drop the JARs with the
right XML implementation into the endorsed dir of Java.

In the end, I forked a new process from my mojo with a custom
classpath and all the necessary options. Much more simple and reliable.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org