Re: Towards Jena 3.11.0
thank you for the link Andy. glad I asked. I will try to keep track of release dates here: http://www.lotico.com/index.php/Apache_Jena On Fri, Apr 19, 2019 at 6:44 PM ajs6f wrote: > https://semver.org/ > > If, for example, we needed to make a quick release for an urgent bugfix, > it would be appropriate to increment only the "micro" or "patch" number. > > ajs6f > > > On Apr 19, 2019, at 1:33 PM, Marco Neumann > wrote: > > > > any particular reason why you add the 0 at the end? > > > > Jena 3.11 would be sufficient > > > > I have seen it in previous releases as well but there is no need to do > > so. is there a build tool that requires this? > > > > Marco > > > > On Fri, Apr 19, 2019 at 5:45 PM Andy Seaborne wrote: > >> > >> OK - I'll prepare Jena 3.11.0. > >> > >> Given the national holidays around this time, be better to have the vote > >> run into next week. > >> > >> Andy > >> > >> On 17/04/2019 21:29, Aaron Coburn wrote: > >>> Also +1 to releasing 3.11 soon and addressing these other issues in > 3.12. > >>> (But either way is fine with me) > >>> > >>> Aaron > >>> > >>> On Wed, Apr 17, 2019 at 6:47 AM wrote: > >>> > +1 to releasing 3.11.0 as described and not loading it up any further. > > ajs6f > > On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne wrote: > > > We seem to be trying to do too much in one release. As ever, people > get > > busy. > > > > https://s.apache.org/jena-3.11.0-jira > >36 JIRA > > > > including fixes like JENA-1657 "Close response stream of http > connections". > > > > While not a major problem at the moment, it can start to cause > blockage > > for other work. > > > > We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and > > immediately start on 3.12.0. I can RM 3.11.0 and have some time to > help > > with a 3.12 ... hoping to get it all done during May. > > > > Or we could just accept a delay to 3.11.0. > > > > It is the usual tension between perfect and timely with volunteer > time! > > > > While my preference is release 3.11.0 now and start 3.12.0, either > is OK > > for me. > > > > Thoughts? > > > > Andy > > > > On 03/04/2019 21:16, Andy Seaborne 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 changes due to > >> BSD-binaries in the combined jars mean some L 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 > >
Re: Towards Jena 3.11.0
https://semver.org/ If, for example, we needed to make a quick release for an urgent bugfix, it would be appropriate to increment only the "micro" or "patch" number. ajs6f > On Apr 19, 2019, at 1:33 PM, Marco Neumann wrote: > > any particular reason why you add the 0 at the end? > > Jena 3.11 would be sufficient > > I have seen it in previous releases as well but there is no need to do > so. is there a build tool that requires this? > > Marco > > On Fri, Apr 19, 2019 at 5:45 PM Andy Seaborne wrote: >> >> OK - I'll prepare Jena 3.11.0. >> >> Given the national holidays around this time, be better to have the vote >> run into next week. >> >> Andy >> >> On 17/04/2019 21:29, Aaron Coburn wrote: >>> Also +1 to releasing 3.11 soon and addressing these other issues in 3.12. >>> (But either way is fine with me) >>> >>> Aaron >>> >>> On Wed, Apr 17, 2019 at 6:47 AM wrote: >>> +1 to releasing 3.11.0 as described and not loading it up any further. ajs6f On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne wrote: > We seem to be trying to do too much in one release. As ever, people get > busy. > > https://s.apache.org/jena-3.11.0-jira >36 JIRA > > including fixes like JENA-1657 "Close response stream of http connections". > > While not a major problem at the moment, it can start to cause blockage > for other work. > > We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and > immediately start on 3.12.0. I can RM 3.11.0 and have some time to help > with a 3.12 ... hoping to get it all done during May. > > Or we could just accept a delay to 3.11.0. > > It is the usual tension between perfect and timely with volunteer time! > > While my preference is release 3.11.0 now and start 3.12.0, either is OK > for me. > > Thoughts? > > Andy > > On 03/04/2019 21:16, Andy Seaborne 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 changes due to >> BSD-binaries in the combined jars mean some L 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
Re: Towards Jena 3.11.0
any particular reason why you add the 0 at the end? Jena 3.11 would be sufficient I have seen it in previous releases as well but there is no need to do so. is there a build tool that requires this? Marco On Fri, Apr 19, 2019 at 5:45 PM Andy Seaborne wrote: > > OK - I'll prepare Jena 3.11.0. > > Given the national holidays around this time, be better to have the vote > run into next week. > > Andy > > On 17/04/2019 21:29, Aaron Coburn wrote: > > Also +1 to releasing 3.11 soon and addressing these other issues in 3.12. > > (But either way is fine with me) > > > > Aaron > > > > On Wed, Apr 17, 2019 at 6:47 AM wrote: > > > >> +1 to releasing 3.11.0 as described and not loading it up any further. > >> > >> ajs6f > >> > >> On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne wrote: > >> > >>> We seem to be trying to do too much in one release. As ever, people get > >>> busy. > >>> > >>> https://s.apache.org/jena-3.11.0-jira > >>> 36 JIRA > >>> > >>> including fixes like JENA-1657 "Close response stream of http > >> connections". > >>> > >>> While not a major problem at the moment, it can start to cause blockage > >>> for other work. > >>> > >>> We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and > >>> immediately start on 3.12.0. I can RM 3.11.0 and have some time to help > >>> with a 3.12 ... hoping to get it all done during May. > >>> > >>> Or we could just accept a delay to 3.11.0. > >>> > >>> It is the usual tension between perfect and timely with volunteer time! > >>> > >>> While my preference is release 3.11.0 now and start 3.12.0, either is OK > >>> for me. > >>> > >>> Thoughts? > >>> > >>> Andy > >>> > >>> On 03/04/2019 21:16, Andy Seaborne 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 changes due to > BSD-binaries in the combined jars mean some L 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
Re: Towards Jena 3.11.0
OK - I'll prepare Jena 3.11.0. Given the national holidays around this time, be better to have the vote run into next week. Andy On 17/04/2019 21:29, Aaron Coburn wrote: Also +1 to releasing 3.11 soon and addressing these other issues in 3.12. (But either way is fine with me) Aaron On Wed, Apr 17, 2019 at 6:47 AM wrote: +1 to releasing 3.11.0 as described and not loading it up any further. ajs6f On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne wrote: We seem to be trying to do too much in one release. As ever, people get busy. https://s.apache.org/jena-3.11.0-jira 36 JIRA including fixes like JENA-1657 "Close response stream of http connections". While not a major problem at the moment, it can start to cause blockage for other work. We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and immediately start on 3.12.0. I can RM 3.11.0 and have some time to help with a 3.12 ... hoping to get it all done during May. Or we could just accept a delay to 3.11.0. It is the usual tension between perfect and timely with volunteer time! While my preference is release 3.11.0 now and start 3.12.0, either is OK for me. Thoughts? Andy On 03/04/2019 21:16, Andy Seaborne 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 changes due to BSD-binaries in the combined jars mean some L 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
Re: Towards Jena 3.11.0
Also +1 to releasing 3.11 soon and addressing these other issues in 3.12. (But either way is fine with me) Aaron On Wed, Apr 17, 2019 at 6:47 AM wrote: > +1 to releasing 3.11.0 as described and not loading it up any further. > > ajs6f > > On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne wrote: > > > We seem to be trying to do too much in one release. As ever, people get > > busy. > > > > https://s.apache.org/jena-3.11.0-jira > >36 JIRA > > > > including fixes like JENA-1657 "Close response stream of http > connections". > > > > While not a major problem at the moment, it can start to cause blockage > > for other work. > > > > We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and > > immediately start on 3.12.0. I can RM 3.11.0 and have some time to help > > with a 3.12 ... hoping to get it all done during May. > > > > Or we could just accept a delay to 3.11.0. > > > > It is the usual tension between perfect and timely with volunteer time! > > > > While my preference is release 3.11.0 now and start 3.12.0, either is OK > > for me. > > > > Thoughts? > > > > Andy > > > > On 03/04/2019 21:16, Andy Seaborne 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 changes due to > > > BSD-binaries in the combined jars mean some L 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 > > >
Re: Towards Jena 3.11.0
+1 to releasing 3.11.0 as described and not loading it up any further. ajs6f On Wed, Apr 17, 2019, 6:14 AM Andy Seaborne wrote: > We seem to be trying to do too much in one release. As ever, people get > busy. > > https://s.apache.org/jena-3.11.0-jira >36 JIRA > > including fixes like JENA-1657 "Close response stream of http connections". > > While not a major problem at the moment, it can start to cause blockage > for other work. > > We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and > immediately start on 3.12.0. I can RM 3.11.0 and have some time to help > with a 3.12 ... hoping to get it all done during May. > > Or we could just accept a delay to 3.11.0. > > It is the usual tension between perfect and timely with volunteer time! > > While my preference is release 3.11.0 now and start 3.12.0, either is OK > for me. > > Thoughts? > > Andy > > On 03/04/2019 21:16, Andy Seaborne 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 changes due to > > BSD-binaries in the combined jars mean some L 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 >
Re: Towards Jena 3.11.0
We seem to be trying to do too much in one release. As ever, people get busy. https://s.apache.org/jena-3.11.0-jira 36 JIRA including fixes like JENA-1657 "Close response stream of http connections". While not a major problem at the moment, it can start to cause blockage for other work. We could release 3.11.0 ASAP (it's 4 months since 3.10.0) and immediately start on 3.12.0. I can RM 3.11.0 and have some time to help with a 3.12 ... hoping to get it all done during May. Or we could just accept a delay to 3.11.0. It is the usual tension between perfect and timely with volunteer time! While my preference is release 3.11.0 now and start 3.12.0, either is OK for me. Thoughts? Andy On 03/04/2019 21:16, Andy Seaborne 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 changes due to BSD-binaries in the combined jars mean some L 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
Re: Towards Jena 3.11.0
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 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 $@ 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 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 changes due to BSD-binaries in the combined jars mean some L 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
Re: Towards Jena 3.11.0
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 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 $@ 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 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 changes due to BSD-binaries in the combined jars mean some L 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
Re: Towards Jena 3.11.0
Found the thread about GeoSPARQL https://jena.markmail.org/thread/3bg3vsathmobvrcl#query:+page:1+mid:itnlkehvwlmsf364+state:results Just tried building it again but I think my knowledge of Gradle is still lacking. It fails with ```* Where: Settings file '/home/kinow/Development/java/jena/geosparql-jena/settings.gradle' line: 3 * What went wrong: A problem occurred evaluating settings 'geosparql-jena'. > Could not find method enableFeaturePreview() for arguments > [STABLE_PUBLISHING] on settings 'geosparql-jena' of type > org.gradle.initialization.DefaultSettings. * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED ``` No matter what I try (tried removing tasks and settings in the gradle file, still no luck). But willing to give it another try after it gets Maven settings. Cheers On Thursday, 4 April 2019, 9:58:58 am NZDT, Bruno P. Kinoshita wrote: >1/ GeoSPARQL >PMC - having more eyes on this would be helpful. I think I left a message somewhere about needing to convert to Maven, and I think I couldn't get it working for some other reason. Will take another look between today and Sunday. >2/ Prometheus metrics Used before, and adding the same tool but in a Python project. Happy to take a look too! And really great to have that in Jena. >3/ SurroundQueryParser Never used this one, I lurked in the initial discussion, but lost track of what was going on. Will review until Sunday too (Saturday family is out, and summer is over in NZ, so whole day for Open Source :D ) CheersBruno On Thursday, 4 April 2019, 9:17:07 am NZDT, Andy Seaborne 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 changes due to BSD-binaries in the combined jars mean some L 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
Re: Towards Jena 3.11.0
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 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 $@ 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 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 changes due to BSD-binaries in the combined jars mean some L 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
Re: Towards Jena 3.11.0
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 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 $@ > > 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 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 changes due to > >> BSD-binaries in the combined jars mean some L 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
Re: Towards Jena 3.11.0
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 $@ 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 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 changes due to BSD-binaries in the combined jars mean some L 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
Re: Towards Jena 3.11.0
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 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 changes due to > BSD-binaries in the combined jars mean some L 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
Re: Towards Jena 3.11.0
>1/ GeoSPARQL >PMC - having more eyes on this would be helpful. I think I left a message somewhere about needing to convert to Maven, and I think I couldn't get it working for some other reason. Will take another look between today and Sunday. >2/ Prometheus metrics Used before, and adding the same tool but in a Python project. Happy to take a look too! And really great to have that in Jena. >3/ SurroundQueryParser Never used this one, I lurked in the initial discussion, but lost track of what was going on. Will review until Sunday too (Saturday family is out, and summer is over in NZ, so whole day for Open Source :D ) CheersBruno On Thursday, 4 April 2019, 9:17:07 am NZDT, Andy Seaborne 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 changes due to BSD-binaries in the combined jars mean some L 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
Towards Jena 3.11.0
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 changes due to BSD-binaries in the combined jars mean some L 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
