Added a POM file for jena-fuseki-geosparql to the same gist:
https://gist.github.com/afs/c6c291812bbc96fe55ac64ecdd1edfe4
Had to do some exclusions on rdf-tables.
Andy
On 07/04/2019 18:42, Andy Seaborne wrote:
Maven is something I can help with: I took a very quick, preliminary
pass and produced:
https://gist.github.com/afs/c6c291812bbc96fe55ac64ecdd1edfe4
That does not include every in the gradle file - I added artifact as
needed to get "mvn clean verify -Drat.skip=true" to run, nothing more.
The one I was unclear about is javax.xml.bind
jdom has a unique license - at a quick glance it looks OK but needs
checking a to the rest of the dependencies. Their intent is "an
Apache-style open source license".
Andy
org.locationtech.jts:jts-core -- EDL - which is category-A.
Redistributions in binary form need the right NOTICE ... except they
don't put the necessary files in their own distribution so I'm unclear
what the intent is here.
Albiston wrote:
Apologies for the delayed reply about the GeoSPARQL module.
There hasn't been much feedback. The main of note was around supporting
equivalent functionality to jena-spatial (property/filter functions,
lat/lon predicates and spatial index), which are now included along with
some other useful property/filter functions.
I'll get onto moving them to Maven etc. but likely next weekend.
Thanks,
Greg
On 03/04/2019 22:33, Marco Neumann wrote:
ok sounds reasonable, so I might be able to move along with jena
spatial
On Wed, Apr 3, 2019 at 10:28 PM Andy Seaborne <a...@apache.org> wrote:
I'm only suggesting removing it from Fuseki, not remove the module.
Fuseki merely includes it.
Putting it back does not even need repacking:
java -cp fuseki-jar:spatial.jar <main class> $@
should work - JenaSystem.init will happen and ServiceLoader cause
spatial to be available as before.
Andy
On 03/04/2019 22:11, Marco Neumann wrote:
ok Andy, I will prepare for the removal of jena spatial from the jena
project. but since I use jena spatial in production it will take a
while
to
switch and I will stay with 3.10 here. what exactly will you do
with the
code base? just remove the code from the fuseki release and the jena
spatial folder in the source?
On Wed, Apr 3, 2019 at 9:17 PM Andy Seaborne <a...@apache.org> wrote:
We have three major streams outstanding.
Have I missed anything?
1/ GeoSPARQL
2/ Prometheus metrics
3/ SurroundQueryParser
== GeoSPARQL
Greg - apologies for being tardy on this one. It looks in good shape.
Did you hear from anyone after the request for feedback?
This is two modules: geosparql-jena and geosparql-fuseki
A suggestion for how to proceed if you have the time for 3.11.0 is
that
we include these basically as-is and remove jena-spatial from Fuseki
which we have been signalling for a while.
Suggestion:
jena-geosparql
jena-fuseki/jena-fuseki-geospatial
and under org.apache.jena.geosparql and
org.apache.jena.fuseki.geosparql
It would have to be maven.
Documentation:
This does not have to timed with the release though desirable to have
some instructions on the website.
Looking the modules, it has its own specialised Fuseki incarnation
with
command line arguments and also internally a system wide
configuration.
maybe, later, we might want to merge the Fuseki setup but exactly how
and whether separate is better for users due to the specialised
nature
can wait. Release should get feedback after it is incorporated -
"release early, release often".
Greg - how does that sound?
PMC - having more eyes on this would be helpful.
If the timing is OK, we can work on details on the ticket JENA-664
(or
email on dev@).
== JENA-1691 : Prometheus metrics
This is getting there. We have the code worked out, the packaging
needs
a bit of discussion; importantly it is missing L&N changes due to
BSD-binaries in the combined jars mean some L&N changes.
== JENA-1690 : SurroundQueryParser
Looks like this is ready and waiting for someone to merge it.
With all that, it looks like some things to sort out.
We can wait a bit longer for 3.11.0, or do 3.11.0 fairly soon with
whatever is ready, including getting things in and expect to further
refine, then advance the timing on 3.12.0.
Thoughts?
Andy