Howdy --
I'm trying to include (and use) a jar in a package, and not having any luck of it just yet. Could I get any guidance on what I might be missing here?
=== BEGIN expath-pkg.xml <package xmlns="http://expath.org/ns/pkg" spec="1.0" name="http://dyfis.net/svnkit-wrapper" abbrev="svnkit" version="0.1"> <title>Subversion Wrapper</title> <xquery> <namespace>http://dyfis.net/svnkit-wrapper</namespace> <file>svn.xq</file> </xquery> </package> === END expath-pkg.xml
=== BEGIN basex.xml <package xmlns="http://expath.org/ns/pkg"> <jar>svnkit-wrapper.jar</jar> <class>net.dyfis.svnkit_wrapper.SvnWrapper</class> </package> === END basex.xml
=== BEGIN svnkit/svn.xq module namespace svnkit = "http://dyfis.net/svnkit-wrapper"; declare namespace j="java:net.dyfis.svnkit_wrapper.SvnWrapper";
declare function svnkit:cat($path as xs:string) as xs:string { j:cat($path) };
declare function svnkit:cat($path as xs:string, $rev as xs:integer) as xs:string { j:cat($path, $rev) }; === END svnkit/svn.xq
...where "svnkit-wrapper.jar" contains a thin wrapper around TMate's SVNKit library, allowing direct access to Subversion resources through a simpler API (providing static functions only, abstracting away session management and the like).
However, when I try to call svnkit:cat($subversion_url), the following is returned:
[XPST0017] Unknown Java function 'net.dyfis.svnkit_wrapper.SvnWrapper.cat(...)'.
I can call net.dyfis.svnkit.wrapper.SvnWrapper("") through Jython and other JVM-based interpreters, so I'm confident that the jar correctly exposes it. Any pointers on what I might be doing wrong in the packaging?
Found one issue (using "strace -f -e trace=file basexhttp"):
BaseX was attempting to look for the file at
$PACKAGE/svnkit/svnkit-wrapper.jar
...whereas I placed it at
$PACKAGE/svnkit-wrapper.jar
However, with this resolved, strace shows that BaseX is successfully locating the wrapper file, but the same XPST0017 error is returned nonetheless.
On 03/21/2012 01:58 PM, Charles Duffy wrote:
Howdy --
I'm trying to include (and use) a jar in a package, and not having any luck of it just yet. Could I get any guidance on what I might be missing here?
=== BEGIN expath-pkg.xml <package xmlns="http://expath.org/ns/pkg" spec="1.0" name="http://dyfis.net/svnkit-wrapper" abbrev="svnkit" version="0.1">
<title>Subversion Wrapper</title> <xquery> <namespace>http://dyfis.net/svnkit-wrapper</namespace> <file>svn.xq</file> </xquery> </package> === END expath-pkg.xml
=== BEGIN basex.xml
<package xmlns="http://expath.org/ns/pkg"> <jar>svnkit-wrapper.jar</jar> <class>net.dyfis.svnkit_wrapper.SvnWrapper</class> </package> === END basex.xml
=== BEGIN svnkit/svn.xq module namespace svnkit = "http://dyfis.net/svnkit-wrapper"; declare namespace j="java:net.dyfis.svnkit_wrapper.SvnWrapper";
declare function svnkit:cat($path as xs:string) as xs:string { j:cat($path) };
declare function svnkit:cat($path as xs:string, $rev as xs:integer) as xs:string { j:cat($path, $rev) }; === END svnkit/svn.xq
...where "svnkit-wrapper.jar" contains a thin wrapper around TMate's SVNKit library, allowing direct access to Subversion resources through a simpler API (providing static functions only, abstracting away session management and the like).
However, when I try to call svnkit:cat($subversion_url), the following is returned:
[XPST0017] Unknown Java function 'net.dyfis.svnkit_wrapper.SvnWrapper.cat(...)'.
I can call net.dyfis.svnkit.wrapper.SvnWrapper("") through Jython and other JVM-based interpreters, so I'm confident that the jar correctly exposes it. Any pointers on what I might be doing wrong in the packaging?
On 03/21/2012 02:24 PM, Charles Duffy wrote:
Found one issue (using "strace -f -e trace=file basexhttp"):
BaseX was attempting to look for the file at
$PACKAGE/svnkit/svnkit-wrapper.jar
...whereas I placed it at
$PACKAGE/svnkit-wrapper.jar
However, with this resolved, strace shows that BaseX is successfully locating the wrapper file, but the same XPST0017 error is returned nonetheless.
After rather a fair bit of time spent trying to track this down --
I'm getting a java.lang.ExceptionInInitializerError for reasons related to my code -- not BaseX's fault, and something I can debug myself.
What *is* unfortunate, however, is that BaseX simply performs a "return null" on any Throwable in Reflect.find(), utterly masking / failing to report an underlying error.
basex-talk@mailman.uni-konstanz.de