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