Re: Towards Jena 3.9.0
More issues including a logging implementation. Setting to "test" in the parent, then adding it as compile does not seem to work with some plugins. On 27/09/18 17:40, Andy Seaborne wrote: FYI First attempt didn't work out. The apache-jena/lib/ didn't have slf4j-log4j or log4j jar files. This is because these are now "true" in the parent (JENA-1595) so apache-jena (the distribution) does not pick them up. Misspoke. JENA-1595 was going from "optional" to "test" Setting to "test" in the parent, then adding it as compile does not seem to work with some plugins - even when dependency:tree shows the jars to be :compile, they do not get included the combined war file. Maybe I haven't got the setting right but my current guess is that inheritance and dependency interact, with inheritance overriding dependency. And "runtime" causes the shade plugin to crash with an NPE. At this point, I'll back out JENA-1595 and try to get something working for the release that is safe, possibly with over some dependency leakage. After release, I can try other ways of managing the logging for cmds/war/fulljar and also the tests at the moment they look like they need time to validate. Andy They ought to be not-optional in jena-cmds which does need a definite choice of logging so it can ensure it is initialized. The Fuseki module and package changes did work in RDF Delta. It is change; I don't know of anyone who depends on them as deeply as this code does although part of the reason for the changes is to enable better extensibility; RDF Delta is not special. Andy On 27/09/18 11:37, ajs6f wrote: +1 ajs6f On Sep 27, 2018, at 6:14 AM, Andy Seaborne wrote: I'm going to start the 3.9.0 release process. Andy
Re: Towards Jena 3.9.0
FYI First attempt didn't work out. The apache-jena/lib/ didn't have slf4j-log4j or log4j jar files. This is because these are now "true" in the parent (JENA-1595) so apache-jena (the distribution) does not pick them up. They ought to be not-optional in jena-cmds which does need a definite choice of logging so it can ensure it is initialized. The Fuseki module and package changes did work in RDF Delta. It is change; I don't know of anyone who depends on them as deeply as this code does although part of the reason for the changes is to enable better extensibility; RDF Delta is not special. Andy On 27/09/18 11:37, ajs6f wrote: +1 ajs6f On Sep 27, 2018, at 6:14 AM, Andy Seaborne wrote: I'm going to start the 3.9.0 release process. Andy
Re: Towards Jena 3.9.0
+1 ajs6f > On Sep 27, 2018, at 6:14 AM, Andy Seaborne wrote: > > I'm going to start the 3.9.0 release process. > >Andy
Re: Towards Jena 3.9.0
I'm going to start the 3.9.0 release process. Andy
Re: Towards Jena 3.9.0
Maven module changes on master : IDEs working with the Apache source impacted. I applied JENA-1597 PR #468 Andy On 19/09/18 11:54, Andy Seaborne wrote: Is targeting end of this month / early next OK for everyone? This release would also remove the distributions of Fuseki1, and SDB. They are still there, but not as zip files. The build process may need tweaks to conform to the new requirement of no MD5 and no SHA1 on /dist/jena as part of the ASF de-emphasising the vulnerable SHA1 - MD5 is already not allowed. I'm happy to RM this release (I can do it on $job time) or alternatively help someone else do it for the first time. One change I'd like to do is to reorganise the Fusek2 modules. JENA-1597 PR #468. I don't know whether many people directly consume the modules. (I nearly said no one would, then found one - it unpacks the war file.) This is to more cleanly separate the webapp/war file version and the embedded version. I'd like to call them "full" and "main". For added featuyre use, the "main" version is much easier to package and extend. The new module structure would be: * jena-fuseki-core : the servlets and registries The full server: * jena-fuseki-webapp : the web application: UI, admin * jena-fuseki-war : package webapp as a WAR file. * jena-fuseki-fulljar : package webapp as a standalone server The main server: * jena-fuseki-main : Current embedded/basic forms in one module. * jena-fuseki-access : Graph access control (see JENA-1594) * jena-fuseki-server : The main server as a combined shared jar. Download: * apache-jena-fuseki : the full server, standalone and war file (unchanged). The maven module name "jena-fuseki-server" is repurposed from shading the webapp as par tof the dist building (proposed: "jena-fuseki-fulljar" ) to shading the "embedded/basic->main" server. A new module is JENA-1594 / jena-fuseki-access - graph level access control, only for the main server currently. Andy Looking at tickets marked "resolved", those that seemed most notable: JENA-1594 Provide per-graph access control in Fuseki (needs documentation and ideally some wrapping to make it easier to use). JENA-1593 Update Apache parent POM to v21 JENA-1585 Reorganize the Fuseki codebase to split the server engine classes from the webapp classes JENA-1573 Remove the jena-fuseki1 distribution JENA-1571 Remove the jena-sdb distribution. JENA-1481 Deleting dataset in Fuseki does not delete dataset permanently JENA-868 Fuseki2: docker: Redirected ports lead to wrong URLs.
Towards Jena 3.9.0
Is targeting end of this month / early next OK for everyone? This release would also remove the distributions of Fuseki1, and SDB. They are still there, but not as zip files. The build process may need tweaks to conform to the new requirement of no MD5 and no SHA1 on /dist/jena as part of the ASF de-emphasising the vulnerable SHA1 - MD5 is already not allowed. I'm happy to RM this release (I can do it on $job time) or alternatively help someone else do it for the first time. One change I'd like to do is to reorganise the Fusek2 modules. JENA-1597 PR #468. I don't know whether many people directly consume the modules. (I nearly said no one would, then found one - it unpacks the war file.) This is to more cleanly separate the webapp/war file version and the embedded version. I'd like to call them "full" and "main". For added featuyre use, the "main" version is much easier to package and extend. The new module structure would be: * jena-fuseki-core : the servlets and registries The full server: * jena-fuseki-webapp : the web application: UI, admin * jena-fuseki-war : package webapp as a WAR file. * jena-fuseki-fulljar : package webapp as a standalone server The main server: * jena-fuseki-main : Current embedded/basic forms in one module. * jena-fuseki-access : Graph access control (see JENA-1594) * jena-fuseki-server : The main server as a combined shared jar. Download: * apache-jena-fuseki : the full server, standalone and war file (unchanged). The maven module name "jena-fuseki-server" is repurposed from shading the webapp as par tof the dist building (proposed: "jena-fuseki-fulljar" ) to shading the "embedded/basic->main" server. A new module is JENA-1594 / jena-fuseki-access - graph level access control, only for the main server currently. Andy Looking at tickets marked "resolved", those that seemed most notable: JENA-1594 Provide per-graph access control in Fuseki (needs documentation and ideally some wrapping to make it easier to use). JENA-1593 Update Apache parent POM to v21 JENA-1585 Reorganize the Fuseki codebase to split the server engine classes from the webapp classes JENA-1573 Remove the jena-fuseki1 distribution JENA-1571 Remove the jena-sdb distribution. JENA-1481 Deleting dataset in Fuseki does not delete dataset permanently JENA-868 Fuseki2: docker: Redirected ports lead to wrong URLs.