Should jena-geosparql be shaded be downloadable without dependencies?

[OyvindLGjesdal]

Version

5.1.0

Question

I get a startup error when dropping jena-geosparql-5.1.0.jar in $FUSEKI_BASE/extra folllowing the instructions

or download the binary from the Maven central repository org/apache/jena/jena-geosparql

in https://jena.apache.org/documentation/geosparql/geosparql-assembler.html

The exception is:

            "Aug 16 16:25:01 instance fuseki-server[2604]: Exception in thread \"main\" java.lang.NoClassDefFoundError: org/jdom2/JDOMException",
            "Aug 16 16:25:01 instance fuseki-server[2604]:         at org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.registerDatatypes(GeometryDatatype.java:69)",
            "Aug 16 16:25:01 instance fuseki-server[2604]:         at org.apache.jena.geosparql.InitGeoSPARQL.init(InitGeoSPARQL.java:54)",
            "Aug 16 16:25:01 instance fuseki-server[2604]:         at org.apache.jena.geosparql.InitGeoSPARQL.start(InitGeoSPARQL.java:38)"
...

If I instead download from https://repo1.maven.org/maven2/org/apache/jena/jena-fuseki-geosparql/ (which is shaded) and put it in the extra folder, the server starts and geosparql works, but when I inspect the jar file it also contains alot (32 MB) of jena and fuseki itself as dependencies, and I think it has the purpose of being a standalone server, and not a drop-in.

See contents of jena-geosparql-5.1.0.jar

Should jena-geosparql also work as a drop-in module for fuseki, or is the purpose to drop in the jena-fuseki-geosparql jar, when using a fuseki-webapp, with geosparql as a module?

[afs]

There is a profile in jena-service-enhancer to do a similar thing.

Only having a shaded jena-geosparql could risk choosing the version of a dependency the application may be including directly.

A hack that may work is to add jena-fuseki-geosparql to extras because the extras are at the end of the classpath. The duplication should be safe and the earlier choices taken. But it is a bit of a hack. (Not tested.)

Long term (no timescale!), I'd like to have jena-fuseki-fulljar be Fuseki Main+modules. There would modules for the admin functions, two UI modules (split in two as "workbench" and "admin UI"), geosparql, Shiro, prometheus and maybe others. It woudl be possible to enable/disable modules from the config.ttl or the command line.

[OyvindLGjesdal]

Thank you for the information.

The jena-service-enhancer jar profile bundle which shades it, is not running during the normal build, and has to be activated, to run. For the short term, would an inactive similar bundle profile for jena-geosparql have the same purpose as moving it to the end of jena-extra, e.g not interfere with dependencies, unless activated? It looks like the bundle profile would have to run from the sub-directories, like the example in the service enhancer docs. The artifacts that needs to be bundled, could then run after the main build has finished, as extra steps? (Changing to directories, running with -Pbundle set).

Long term solution sounds neat. A fork of AFS/fuseki-mods, https://github.com/AKSW/fuseki-mods/tree/adaptions/jena-fmod-geosparql added geosparql as one of the modules, but is a bit behind on version.

In my experience there seems to often be issues with dropping in jars. New missing classes from dependencies etc., I should try to use/learn a more maven/java centric configuration/setup.

[Aklakan]

A fork of AFS/fuseki-mods, https://github.com/AKSW/fuseki-mods/tree/adaptions/jena-fmod-geosparql added geosparql as one of the modules, but is a bit behind on version.

Just a note on the fork: The module uses an adapted version of jena-geosparql (based on our AKSW/jena fork) where @LorenzBuehmann and @SimonBin added support for having spatial indexes on a per graph basis. The current module only supports one index over all graphs. The fuseki module also adds a little servlet where one can manually trigger recreation of the index for selected graphs or all.

The main problem is, that jena-geosparql somewhat incorrectly builds upon the Resource abstraction, whereas Node would have been better, because the latter is serializable and the former not. So Lorenz retrofitted serialization with kryo but this is under BSD3 license and AFAIK incompatible with Apache V2. The right solution would be to replace most references to Resource with Node in jena-geosparql, but unfortunately so far we didn't have time to address this.

(An evaluation of this was also part of our GeoSPARQL/Jena presentation at the GeoLD workshop at ESWC2024: slides, p15, p16. When we find time we'd like to contribute the good parts back, but so far no timeline.)

Of course we'd also favor a long term solution for managing Fuseki modules.

[afs]

The conditions for other licenses is at https://www.apache.org/legal/resolved.html with many licenses already approved.

"cat-A" is fine; it may need updates to the appropriate NOTICE file.
The top level NOTICE applies to the source code in the repository.
The binaries have different, longer NOTICE files. If it is unmodified kryo, it is a binary dependency.

"cat-B" is, roughly, "with care and binary only" and not in the formal source release (the jena-X.Y.Z-source-release.zip file).

"cat-X" is not possible due to imposing additional conditions on the work, restrictions on use, and various other reasons.

BSD3 (if you mean 3-clause BSD - the "BSD" name is used for quite a lot of things) is cat-A - including source code.

The Eclipse Distribution License is 3-clause BSD. (The Eclipse Public License is not).