Hi Andy,

Just a big +1 for everything you've done here. I confess that I've still mostly been using Fuseki1 for various quick jobs, such as setting up a temporary SPARQL endpoint for myself and testing out new functionality related to jena-text and/or jena-spatial. I do use Fuseki2 on some servers, but not all of them.

My general feeling has been that I know how Fuseki1 works and can run it from the command line whenever I want without any side effects, whereas with Fuseki2 I need to think hard every time I want to use it. Part of that is just personal inertia but it seems you are sorting out the actual technical issues behind this perception, which is great!

-Osma

Andy Seaborne kirjoitti 29.05.2017 klo 19:18:
The recent Fuseki pull requests (JENA-1347:PR#254 and JENA-1350:PR#256) are to do replacing all use of Fuseki1.

That means:
A/ Replace all testing use with Fuseki2 embedded
B/ have a simple way a Fuseki, with validators, to run with diffeent static content and no UI.

With the PR's the codebase has no use of Fuskei1 by other modules.

Getting a Fuskei setup for sparql.org is done but not full tested and not contributed yet (thinking about where to put the code).

     Andy

Changes are:

1/ Validator reorg

The validators in Fuseki2 output JSON, expecting the client to run javascript to format for human presentation. SPARQLer is better if it is simple, no JS, so the HTML-generating validators from Fuseki1 have been ported to Fuseki2 and for each there is a servlet to decide whether it is an HTML or JSON request based on conneg, then call functions to generate JOSN or HTML

2/ Use embedded Fuseki for testing - it has no on-disk work area and does not run as a full webapp using web.xml for configuration.

Embedded Fuseki is jetty+servlets and so is much like Fuseki1.

jena-jdbc-driver-remote and -bundle used Fuseki1 and their usage has been replaced.

3/ General clearing up.

No more use of "ServerCtl" from full Fuseki - use Embeded Fuseki for testing.

4/ A command line way to use the embedded s-version of Fuseki. This can then be run as SPARQLer at sparql.org.

What we now have a "basic Fuseki" command-line running of Fuseki without the on-disk state area, nor Shiro. Maybe useful to people as a development tool.

I need to integrate with the PR's in progress (it works locally) and them I'll contribute this, either added to jena-fuseki-embedded or a new module. It's one class - the command line code that calls the Fuseki embedded builder - and some shading to build a single runnable jar (no Shiro jar, no jena-text jar and includes all of jena-cmds).

So we have 3 variants of Fuseki2's: Full, Embedded and Basic.

"Fuseki Full" remains the binary put up on /dist/jena.

Fuseki1 can be removed from /dist/jena.

Structure:

The jena-fuseki2 module structure isn't really the ideal setup now but is harmless. Might be worth sorting out eventually when the requirements are clear and also depending on what people thing about having many modules given that each way to shade or assembly binaries needs a module to produce an deployable artifact (or some long names with the version and classifier in them and use <shadedArtifactAttached>).






--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
[email protected]
http://www.nationallibrary.fi

Reply via email to