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 > >> > -- --- Marco Neumann KONA
