Yes and I have now done that for this case. However when prototyping it is sometimes nice to quickly try things out to see what might work without the burden of firing up a Java IDE, managing the source etc.

Regards
/Andy



On Fri, Jan 3, 2014 at 11:05 AM, Florent Georges <fgeorges@fgeorges.org> wrote:
  Yet another solution (probably the one I prefer) would be to write
your own Java class, exposing exactly the API you need, taking care of
the interface between XQuery and Java, and deferring actual hard work
to the library.

  Regards,

--
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/


On 3 January 2014 11:25, Andy Bunce wrote:
> Or maybe better with a pragma e.g.
>
> return tika:parse(
>       (# basex:java-type java:java.io.File #){$file}
> )
>
>
> On Thu, Jan 2, 2014 at 5:42 PM, Andy Bunce <bunce.andy@gmail.com> wrote:
>>
>> Hi,
>>
>> In my ongoing attempts to use various Java libraries, without writing any
>> Java myself, I have trying  Apache Tika.
>> (http://tika.apache.org/1.4/api/org/apache/tika/Tika.html). With the tika
>> jar on the classpath I hoped the following would work:
>>
>> import module namespace tika = "java:org.apache.tika.Tika";
>> declare namespace File="java:java.io.File";
>> let $file :=File:new("xx.pdf")
>> return tika:parse($file)
>>
>> It generates the error
>> Signature 'org.apache.tika.Tika.parse' is ambiguous
>>
>> Which maybe it is from some perspectives :-). I hoped some type
>> information might be available in the $file variable to resolve this, but it
>> appears not.
>> I was wondering about the possibility of  using Java type at the XQuery
>> level e.g.
>> let $file as java:java.io.File :=File:new("xx.pdf")
>>
>> Is there any way to avoid writing the couple of line Java class shim for
>> this and similar cases?
>>
>> Regards
>> /Andy
>
>
>
> _______________________________________________
> BaseX-Talk mailing list
> BaseX-Talk@mailman.uni-konstanz.de
> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
>