Hi Andy, Hooray on seeing the new UI. I'm updating the JS dependencies (things move fast in JS!), and should have a PR ready for review soon-ish. Only issue was a new version of Bootstrap, but shouldn't be a big issue. I'll start adding unit tests, and later e2e tests, but this shouldn't block a release, since manually testing Fuseki is not too hard as it's a small app at the moment.
>== javax-jakarta transition> (...) >commons-fileupload code does not update very often (last version was >2018). It is small and Fuseki only uses a small part of it so we could >adopt the code we need for file upload from HTML pages. If there's an easy fix for commons-fileupload I can try to work with others to get it merged and then release it (I'm working on a commons-imaging release ATM) As for the WAR and standalone versions; I don't understand very well all the packaging, and how users are running it. I think the Java layer could be just standalone app, with assembly/maven-plugins to create a separate WAR file to upload with the release if users want/need it. The Vue UI, at the moment, produces a single app. But we could organize it in a similar way. Have the core code in a JS module, and another JS module that consumes the core, and produces a complete UI with admin + query/editor. Or we could have separate JS modules. One for sparqler, one for admin, one for query/editor (just would need to move the common components to the core module). But starting simple as we are doing is a lot easier. I think you might be the best one to tell how the UI must evolve :) I'm just happy to see the dependencies managed with npm/yarn. We might start seeing dependabot PR's for JS soon. Here's an example of an application with multiple modules, which uses TypeScript but we don't need to use TypeScript if we don't want to: https://github.com/jupyterlab/jupyterlab/tree/master/packages. They work similar to Maven modules, with the parent module as the maven parent https://github.com/jupyterlab/jupyterlab/blob/602b05399b0ca762613c8f560a49b15abdefee39/package.json#L6-L25. Thanks! -Bruno On Monday, 3 January 2022, 05:23:11 am NZDT, Andy Seaborne <a...@seaborne.org> wrote: A collection of thoughts and discussion points about Fuseki. == Jena 4.4.0 There is a vue-based rewrite of the UI thanks to Bruno (yea!). The new UI is in the codebase and the LICENSE and NOTICE files updated. There are no blockers for releasing this in 4.4.0 release. Prior to the kerfuffle over security, the hope was an earlier-then-usual 4.4.0 because the UI only just missed 4.3.x. == javax-jakarta transition jakarta is JavaEE at the Eclipse Foundation). At some time, there will need to be transition from javax.* to jakarta.* for the package imports of javax.* that relate to Java EE. For Fuseki that is mainly for javax.servlet but also an implication for the WAR file. For the Fuseki code itself, there isn't much impact, just a rename. Partially this is because Fuseki does not use JavaEE features. For example, request dispatch is not done with web.xml (Fuseki dispatch is dynamic, not a static setup). FusekiMain does not use web.xml at all. Jetty version 11 is the same as Jetty version 10 except that "javax" -> "jakarta" renaming. A big bang switch over but it should be mechanical translation. There are two dependencies that use javax.servlet -- commons-fileupload and shiro. commons-fileupload code does not update very often (last version was 2018). It is small and Fuseki only uses a small part of it so we could adopt the code we need for file upload from HTML pages. shiro is an unknown. The WAR file is more of a problem - we have already had someone try to run Fuseki in Tomcat 10 and it fails. All Tomcat 9 webapps fail in Tomcat 10. Tomcat10 is based on jakarta while Tomcat9 is javax. Tomcat has a migration tool: tomcat-jakartaee-migration but otherwise it's a incompatible change. (I haven't tried the tool). I haven't come across the reverse conversion. Maybe maven-shade-plugin will do it. == Distributing the WAR file. The apache-jena-fuseki zip/tar.gz download is getting quite big. It has both the war file and the standalong Fuseki server (jena-fuseki-fulljar). One option is to change to providing the WAR file by a link on the project download page, and note in the apache-jena-fuseki README. The link could be in /binaries or to maven central. What is hard to determine is how important the war file version actually is nowadays. Should we focus on a runnable server Fuseki or are multi-webapp hosting containers still common for semantic web data? Or change the WAR file to be less webapp internally? Have a simple "all URLs" grabber in web.xml and feed it into a wrapped FusekiMain? == Standalone server - switch to Fuseki Main+UI Ideally, long term, the standalone server would switch to being Fuseli/Main + UI + Admin module. At the moment it is Jetty+and the same code as the war file version. More on Fuseki modules below. Fuseki/main and Fuseki/webapp differ in how they startup and whether the additional servlets like admin are routed by web.xml or configured by the HTTP server builder in java code setup directly into Jetty. == Modules A Fuseki Module is loadable code that gets called in the server lifecycle, principally getting called during server build with direct access into the Fuseki server datastructures. A module can add new features, modify the Fuseki server as it is being built or simply monitor operations. It only works with FusekiMain - FusekiMain has a clearly defined lifecycle. The webapp is a "build-once" but also tied to the fixed web.xml routing. https://github.com/apache/jena/blob/main/jena-fuseki2/jena-fuseki-main/src/main/java/org/apache/jena/fuseki/main/sys/FusekiModule.java This has been "experimental" in 4.3.x. I have (not-production-ready) modules: FMod_UI: jar file serving the static content of the UI JS/CSS/HTML directly from the jar file. No fixed disk area for static content. FMod_Admin: makes the admin code work as a Fuseki module. This would also be a chance to simplify the design. Thius experimental module is compatible with the on-disk layout of FusekiWebapp admin. FMod_Shiro (sktech): looks possible. A Fuseki module can add servlet filters to the servlet dispatch chain. FMod_FusekiKafka: Adds Kafka topics as an data input channel to Fuseki. It can transport data, patches or SPARQL Update requests and routes them to a dataset. (£job related.) FMod_ProvidePATCH: Add handling of HTTP verb PATCH. This is in "ExFusekiMain_3_FusekiModule.java" FMod_GraphAccessCtl: Configure the graph level security (jena-fuseki-access). FMod_ABAC: (£job related). Triple level attribute-based security. And recently mentioned: FMod_GeoSPARQL as a way of delivering jena-fuseki-geosparql capability in a general FusekiMain server. Some of these generate a new requirement not currently supported - the ability to add arguments to the command line. Andy
