On 5/25/12 10:25 AM, "Paolo Castagna" <castagna.li...@googlemail.com> wrote:
>Hi Rob > >Robert Vesse wrote: >> In the context of the discussion of next releases maybe this is a good >>time to revisit the topic of LARQ and its integration with Fuseki >> >> As I understand it right now the way to deploy LARQ is to modify the >>Fuseki POM to pull in the LARQ dependency so that one can built a >>modified Fuseki uber jar with the LARQ and Lucene features enabled? >>Paolo please correct me if I am mistaken > >Exactly. See also https://issues.apache.org/jira/browse/JENA-63 (which >has an >up-to-date patch attached). > >> In the interests of extensibility maybe it would be better to move to a >>model that allow for easier drop in extension of Fuseki. What I'm >>thinking is that you have an empty lib directory in the Fuseki >>distribution and then rather than having users call the JAR directly you >>have a simple script that invokes the JAR and instantiates the class >>path to be lib/* thereby picking up any drop in extensions users have > >It's a possibility, but you lose the advantage and simplicity of >everything in a >single JAR (and from what I can see, people (including me) like it... a >lot!). > >Also, you need to make sure you put under ../lib all the necessary jars. >For LARQ, for example, this includes Lucene as well as LARQ jar itself. >Easy/trivial (but some manage to get this wrong and/or they mix and match >wrong >versions when they do things manually). There's nothing to stop us making LARQ generate an uber-jar in the same way we do for Fuseki with maven shade is there? This would be sufficient for users if they only had to drop in a single extra JAR into a directory - most users can manage that ;-) > >> It may even be sensible to move the Fuseki JAR into that lib directory >>and just invoke java with a class path of lib/* and call out the main >>class FusekiCmd explicitly and not use the jar argument at all e.g. >> >> #!/bin/bash >> >> Java cp lib/* org.apache.jena.fuseki.FusekiCmd $* >> >> Forgive me if the above syntax is not exactly correct and you'd maybe >>want to do some JAVA_HOME shenanigans in there but hopefully you get the >>general idea. >> >> Is this a sensible suggestion? > >I have no strong opinion about this. > >Personally, I prefer to have a single jar and use java -jar ... (but, >it's just >me and my preference). I can see the advantages of what you suggest. But, >even >if we do it, I would probably still 'patch' things and build my own >single jar. > >> It seems like it would make it easier to drop in proposed future >>extensions like GeoSPARQL without getting into users having to recompile >>the code themselves. > >I don't disagree on the principle. > >I think allowing users to drop in extensions (plug-ins) to Fuseki is >really an >useful feature. > >Some use ServiceLoader (+/- a dependency injection framework), others >write >their own plug-in framework, others use a third party plug-in framework. >Some >use OSGi, etc. Jena has Assemblers, but I am not sure they can be >stretched that >far. Yes that is my concern that we're making users jump through a lot of hoops to extend things I thought assemblers can be used to get arbitrary classes loaded so can you not theoretically have some initializer class for the plugin (whether LARQ or otherwise) and add lines to the assembler to get it loaded. It seems like assemblers would solve other current problems with LARQ such as the ability to specify custom analyzers, index directories etc. Doing everything via assembler seems the logical way to go for plugins like LARQ > >I do not have enough experience with Assemblers to know if it is actually >possible to drop in a jar (which extends ARQ) in the classpath and have >Fuseki >picking it up transparently. When I tried to do that with LARQ, I failed >and I >needed to make small (and very ugly) changes in ARQ (which does not feel >right). > >To summarize, I am not against or over exited by what you suggest. >It makes sense, but I would probably not use it. >In Apache lingo, I would say: 0. > >Paolo > >> >> Rob >> > Rob
