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). > 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. 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 >
