jaxen-from-packaged-dom4j: where to place in CLASSPATH

[Stefan Bodewig <bo...@apache.org>]

Hi,

if you are fast, you can see that jaxen-from-packaged-dom4j fails on
"traditional" Gumps at
<http://gump.covalent.net/log/jaxen-from-packaged-dom4j.html>.

The reason is this:

[javac] Compiling 23 source files to /data/gump/jaxen/target/test-classes 
[javac] /data/gump/jaxen/src/java/test/org/jaxen/AddNamespaceTest.java:124: unreported exception org.jaxen.JaxenException; must be caught or declared to be thrown 
[javac] super( expr ); 
[javac] ^ 
[javac] /data/gump/jaxen/src/java/test/org/jaxen/JaxenHandlerTest.java:158: setXPathHandler(org.jaxen.saxpath.XPathHandler) in org.jaxen.saxpath.SAXPathEventSource cannot be applied to (org.jaxen.JaxenHandler) 
[javac] reader.setXPathHandler( handler ); 
[javac] ^ 
[javac] /data/gump/jaxen/src/java/test/org/jaxen/JaxenHandlerTest.java:203: setXPathHandler(org.jaxen.saxpath.XPathHandler) in org.jaxen.saxpath.SAXPathEventSource cannot be applied to (org.jaxen.JaxenHandler) 
[javac] reader.setXPathHandler( handler ); 
[javac] ^ 
[javac] 3 errors

It doesn't fail on Gumpy and I've been trying to find out why.  Taking
the very first error, it is the constructor of

class MockXPath extends BaseXPath

with

    public MockXPath(String expr) throws SAXPathException

and in src/java/main/org/jaxen/BaseXPath.java we find

    protected BaseXPath(String xpathExpr) throws JaxenException

As JaxenException extends SAXPathException this should compile.

Digging deeper, there is another BaseXPath class coming in from
dom4j-full.jar in the packaged dom4j project, JaxenException is there
as well.  It seems as if JaxenException didn't extend SAXPathException
in that version.

In "traditional" Gump, <work> elements get appendend to the CLASSPATH
while Gumpy prepends them.  So in "traditional" Gump we should pick up
the classes from dom4j-full.jar while Gumpy sees the one from the
<work> entry.

So, should <work> get to the front or the end of the CLASSPATH?
Adding it to the front seems right as long as it doesn't get abused to
point to jars of released versions inside the CVS tree, but I may be
missing a reason why "traditional" Gump works the way it does right
now.

Stefan

Re: jaxen-from-packaged-dom4j: where to place in CLASSPATH

[Stefan Bodewig <bo...@apache.org>]

On Wed, 11 Feb 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:

> I feel we need to start to migrate the knowledge from your
> head/traditional Gump into documentation, or we'll never have a
> community that can self-diagnose, self-manage.

Understood. 8-)

I'll see what I can do.

Stefan

Re: jaxen-from-packaged-dom4j: where to place in CLASSPATH

["Adam R. B. Jack" <aj...@trysybase.com>]

Stefan responded:

> > I am also willing to leave Gumpy as the "correct" way,
>
> OK, done.

I feel we need to start to migrate the knowledge from your head/traditional
Gump into documentation, or we'll never have a community that can
self-diagnose, self-manage.

Could I ask you to update the xdocs for this decision?

regards

Adam

Re: jaxen-from-packaged-dom4j: where to place in CLASSPATH

[Stefan Bodewig <bo...@apache.org>]

On Tue, 10 Feb 2004, Scott Sanders <sc...@dotnot.org> wrote:

> I am also willing to leave Gumpy as the "correct" way,

OK, done.

Stefan

Re: jaxen-from-packaged-dom4j: where to place in CLASSPATH

[Scott Sanders <sc...@dotnot.org>]

> I'm willing to change my opinion of almost two years ago and make
> "traditional" Gump behave like Gumpy here.  If you want to cheat,
> that's probably your problem.
>
> Thoughts?
>

I am also willing to leave Gumpy as the "correct" way, unless someone 
else speaks up and says otherwise.  If someone wants to cheat, they can 
submit a patch for a <cheat/> element :)

Scott

Re: jaxen-from-packaged-dom4j: where to place in CLASSPATH

[Stefan Bodewig <bo...@apache.org>]

On Tue, 10 Feb 2004, Stefan Bodewig <bo...@apache.org> wrote:

> I may be missing a reason why "traditional" Gump works the way it
> does right now.

well, at least I now know that I made sure it does:

<http://marc.theaimsgroup.com/?l=alexandria-dev&m=102585469601635&w=2>

and found this thread

<http://marc.theaimsgroup.com/?l=alexandria-dev&m=102517311610649&w=2>

So putting <work> last ensures that you can't cheat by pointing to
jars in CVS while putting it first ensures you compile against the
latest code in situations where there are duplicate classes.

I'm willing to change my opinion of almost two years ago and make
"traditional" Gump behave like Gumpy here.  If you want to cheat,
that's probably your problem.

Thoughts?

Stefan