Hi jerven,
Firstly, better to copy the whole package ... one package split across
jars goes wrong in weird and mysterious ways sometimes.
While there a few protected methods in FusekiMain, it doesn't look like
it can be done - adding the arguments is easy enough, but processing
them doesn't have the right hook and there is at least one error message
that has the backend choices in the error string.
To use as currently released, a script could have an assembler file and
set the dataset up that way. The other command line arguments still
apply. Would that work?
We could add the flexibility; it might be good to have all choices as
"options" so that can be excluded to produce specialised versions of the
command line invocation.
Another reason for cloning the the package - if these changes happen, it
is going to incompatible with previous versions so isolating from the
other classes would be greater stability.
Recorded as:
https://issues.apache.org/jira/browse/JENA-2268
Andy
On 01/02/2022 15:00, jerven Bolleman wrote:
Dear All,
This is relation to the HDT-java project upgrade to Jena4
(https://github.com/rdfhdt/hdt-java/pull/144).
In the past before I was involved in anyway, there was a hard copy of
the launcher class for Fuseki. Mostly to add one new option to FusekiCmd
and no real other use case.
e.g. there are --tdb2, --tdb1, --mem and the HDT crew wanted to add --hdt.
Now they at the time just copied most of the code and added that one
option.
However this is not great maintenance wise, what would be a better way
to do this ?
Regards,
Jerven
