[jira] [Resolved] (JENA-2221) Remove usage of Apache HttpClient in transition code.
[ https://issues.apache.org/jira/browse/JENA-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne resolved JENA-2221. - Resolution: Done > Remove usage of Apache HttpClient in transition code. > - > > Key: JENA-2221 > URL: https://issues.apache.org/jira/browse/JENA-2221 > Project: Apache Jena > Issue Type: Task > Components: ARQ, JSON-LD >Affects Versions: Jena 4.3.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Major > Fix For: Jena 4.4.0 > > > At Jena 4.3, HTTP usage was switched from using Apache HttpClient (JENA-2125) > to using java.net.http. The support code and old HTTP query engine were left > in place to smooth transition. > This ticket completes the transition by removing the legacy code. > There will still be scope=runtime dependencies on some Apache HttpClient > artifacts because jsonld-java uses Apache HttpClient. Jena has direct > dependencies on the artifacts to control the version used, both to keep it > up-to-date and also resolve some dependency convergence issues that arise on > artifacts used by Apache HttpClient and other Jena dependencies. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (JENA-2220) Move Apache HttpClient-related code into jena-jdbc
[ https://issues.apache.org/jira/browse/JENA-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne resolved JENA-2220. - Resolution: Done > Move Apache HttpClient-related code into jena-jdbc > -- > > Key: JENA-2220 > URL: https://issues.apache.org/jira/browse/JENA-2220 > Project: Apache Jena > Issue Type: Task > Components: JDBC >Affects Versions: Jena 4.3.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 4.4.0 > > > At Jena 4.3, HTTP usage was switched from using Apache HttpClient (JENA-2125) > to using java.net.http. The support code and old HTTP query engine were left > in place to smooth transition. > The exception was jena-jdbc. It exposes some Apache HttpClient classes. > This ticket is to move the necessary Apache HttpClient related code into > jena-jdbc so that the main Jena system does not have a compile time > dependency on Apache HttpClient. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JENA-2221) Remove usage of Apache HttpClient in transition code.
[ https://issues.apache.org/jira/browse/JENA-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463192#comment-17463192 ] ASF subversion and git services commented on JENA-2221: --- Commit 6dc49d7e1aa2fd00bf958823535a34dd8911c41f in jena's branch refs/heads/main from Andy Seaborne [ https://gitbox.apache.org/repos/asf?p=jena.git;h=6dc49d7 ] JENA-2221: Remove Apache HTTP Client usage > Remove usage of Apache HttpClient in transition code. > - > > Key: JENA-2221 > URL: https://issues.apache.org/jira/browse/JENA-2221 > Project: Apache Jena > Issue Type: Task > Components: ARQ, JSON-LD >Affects Versions: Jena 4.3.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Major > Fix For: Jena 4.4.0 > > > At Jena 4.3, HTTP usage was switched from using Apache HttpClient (JENA-2125) > to using java.net.http. The support code and old HTTP query engine were left > in place to smooth transition. > This ticket completes the transition by removing the legacy code. > There will still be scope=runtime dependencies on some Apache HttpClient > artifacts because jsonld-java uses Apache HttpClient. Jena has direct > dependencies on the artifacts to control the version used, both to keep it > up-to-date and also resolve some dependency convergence issues that arise on > artifacts used by Apache HttpClient and other Jena dependencies. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JENA-2221) Remove usage of Apache HttpClient in transition code.
[ https://issues.apache.org/jira/browse/JENA-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463193#comment-17463193 ] ASF subversion and git services commented on JENA-2221: --- Commit 511ee1fcceb3da664fa52a3e8955e79775b9a9a9 in jena's branch refs/heads/main from Andy Seaborne [ https://gitbox.apache.org/repos/asf?p=jena.git;h=511ee1f ] Merge pull request #1134 from afs/pom-dev2 JENA-2221: Remove Apache HTTP Client usage > Remove usage of Apache HttpClient in transition code. > - > > Key: JENA-2221 > URL: https://issues.apache.org/jira/browse/JENA-2221 > Project: Apache Jena > Issue Type: Task > Components: ARQ, JSON-LD >Affects Versions: Jena 4.3.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Major > Fix For: Jena 4.4.0 > > > At Jena 4.3, HTTP usage was switched from using Apache HttpClient (JENA-2125) > to using java.net.http. The support code and old HTTP query engine were left > in place to smooth transition. > This ticket completes the transition by removing the legacy code. > There will still be scope=runtime dependencies on some Apache HttpClient > artifacts because jsonld-java uses Apache HttpClient. Jena has direct > dependencies on the artifacts to control the version used, both to keep it > up-to-date and also resolve some dependency convergence issues that arise on > artifacts used by Apache HttpClient and other Jena dependencies. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JENA-2220) Move Apache HttpClient-related code into jena-jdbc
[ https://issues.apache.org/jira/browse/JENA-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463190#comment-17463190 ] ASF subversion and git services commented on JENA-2220: --- Commit 65586f7c039b0f613b1ea16adee833c03cd2e620 in jena's branch refs/heads/main from Andy Seaborne [ https://gitbox.apache.org/repos/asf?p=jena.git;h=65586f7 ] JENA-2220: Isolate Apache HTTP Client usage in jena-jdbc > Move Apache HttpClient-related code into jena-jdbc > -- > > Key: JENA-2220 > URL: https://issues.apache.org/jira/browse/JENA-2220 > Project: Apache Jena > Issue Type: Task > Components: JDBC >Affects Versions: Jena 4.3.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 4.4.0 > > > At Jena 4.3, HTTP usage was switched from using Apache HttpClient (JENA-2125) > to using java.net.http. The support code and old HTTP query engine were left > in place to smooth transition. > The exception was jena-jdbc. It exposes some Apache HttpClient classes. > This ticket is to move the necessary Apache HttpClient related code into > jena-jdbc so that the main Jena system does not have a compile time > dependency on Apache HttpClient. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JENA-2220) Move Apache HttpClient-related code into jena-jdbc
[ https://issues.apache.org/jira/browse/JENA-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463191#comment-17463191 ] ASF subversion and git services commented on JENA-2220: --- Commit b78cef5c2857407b8210deaf71d9959b2af7a154 in jena's branch refs/heads/main from Andy Seaborne [ https://gitbox.apache.org/repos/asf?p=jena.git;h=b78cef5 ] Merge pull request #1133 from afs/pom-dev1 JENA-2220: Isolate Apache HTTP Client usage in jena-jdbc > Move Apache HttpClient-related code into jena-jdbc > -- > > Key: JENA-2220 > URL: https://issues.apache.org/jira/browse/JENA-2220 > Project: Apache Jena > Issue Type: Task > Components: JDBC >Affects Versions: Jena 4.3.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 4.4.0 > > > At Jena 4.3, HTTP usage was switched from using Apache HttpClient (JENA-2125) > to using java.net.http. The support code and old HTTP query engine were left > in place to smooth transition. > The exception was jena-jdbc. It exposes some Apache HttpClient classes. > This ticket is to move the necessary Apache HttpClient related code into > jena-jdbc so that the main Jena system does not have a compile time > dependency on Apache HttpClient. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (JENA-2212) Single root for all dataset assemblers.
[ https://issues.apache.org/jira/browse/JENA-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne resolved JENA-2212. - Resolution: Done > Single root for all dataset assemblers. > --- > > Key: JENA-2212 > URL: https://issues.apache.org/jira/browse/JENA-2212 > Project: Apache Jena > Issue Type: Improvement >Affects Versions: Jena 4.3.1 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 4.4.0 > > > A single root abstract class for all datasets assemblers would make them > easier to find during development. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (JENA-1911) Update Fuseki 2 UI JS code
[ https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated JENA-1911: Priority: Major (was: Minor) > Update Fuseki 2 UI JS code > -- > > Key: JENA-1911 > URL: https://issues.apache.org/jira/browse/JENA-1911 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 4.3.2 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: Jena 4.4.0 > > Attachments: image-2020-06-05-12-09-57-685.png, > image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, > image-2020-06-05-12-15-19-199.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > The existing Jena Fuseki user interface uses Backbone.js, with extra > libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, > which is largely supported now. > This issue is a placeholder for discussion & work around updating the UI. > Using ES6 in the code would be a great improvement. > But I also suggesting adopting a different framework. The most famous > framework for JS UI is probably React, followed by Angular & Vue. I am using > Vue.js at $work, so I am biased. > The reason we chose Vue.js at work is that the development team is using > mainly Python, with background in Perl, C, and Shell. So out of the three, > Vue.js was the simplest, as it didn't require TypeScript, special syntax, and > the tools required to build an app with Vue are also quite simple. > One downside of this approach is the build of Apache Jena, which would > require Node.js and a build tool like Yarn or NPM. But it also brings > benefits such as: > * We can write unit tests for the UI > * We can write integration (e2e, end to end) tests with Cypress or > Nightwatch (similar to Selenium, but simpler to run and maintain) > * It will be easier to keep the code up to date, as tools like GitHub > security bot are able to inspect package.json and look for outdated or > libraries with CVE's > * It will be easier to incorporate other libraries in the code, so that we > can easily switch the JS code for the editor (for example), or add a new > library to handle SPARQL, etc > * It is now easier to find developers that know Vue, React, Angular, than > Backbone (though that was the first framework I learned, and I really like > it), so maybe we would get more contributors to help with Fuseki UI > So features we would have after this issue: > * Application built with ES6 JavaScript code > * Using Vue.js as framework for the UI > * Adding accessibility support (WCAG 2.0, mybe covering section 508 > though I'm not quite familiar as that's more for US) > * Update all the JS libraries > * Add documentation to the code with JSDoc (the current code lacks > documentation) > * Add tests, both unit and end-to-end (also not present in current code) > * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. > users are already familiar with Fuseki, and know they can upload data, run > queries, etc, so we should make sure that they are able to find it) > * Theming, with a default light-mode, a dark-mode, and (possibly?) > color-blind or other custom themes > * Work on mobile/responsive viewports > * Local browser settings; this is something cheap, that doesn't require > changing to the backend, and would allow us to persist user settings such as: > ** Previous executed Queries > ** Extra query prefixes > ** Number of datasets displayed per page in the main page > ** How long the server status widget queries the server (i.e. should we ping > it every 1 hour? every 30 seconds?) > ** The theme of the user (dark, light, color-blind-protanopia, > high-contrast, etc) leveraging bootstrap-vue > ** User language -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JENA-2212) Single root for all dataset assemblers.
[ https://issues.apache.org/jira/browse/JENA-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463153#comment-17463153 ] ASF subversion and git services commented on JENA-2212: --- Commit cbf5c5ed5d43c690601a002c41d24f6e47f6ef98 in jena's branch refs/heads/main from Andy Seaborne [ https://gitbox.apache.org/repos/asf?p=jena.git;h=cbf5c5e ] JENA-2212: Common root DatasetAssembler > Single root for all dataset assemblers. > --- > > Key: JENA-2212 > URL: https://issues.apache.org/jira/browse/JENA-2212 > Project: Apache Jena > Issue Type: Improvement >Affects Versions: Jena 4.3.1 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 4.4.0 > > > A single root abstract class for all datasets assemblers would make them > easier to find during development. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JENA-2212) Single root for all dataset assemblers.
[ https://issues.apache.org/jira/browse/JENA-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463154#comment-17463154 ] ASF subversion and git services commented on JENA-2212: --- Commit da5921bc9ff412a4b5a25595092d5ca9287b9d97 in jena's branch refs/heads/main from Andy Seaborne [ https://gitbox.apache.org/repos/asf?p=jena.git;h=da5921b ] Merge pull request #1132 from afs/ds-assembler JENA-2212: Common root DatasetAssembler > Single root for all dataset assemblers. > --- > > Key: JENA-2212 > URL: https://issues.apache.org/jira/browse/JENA-2212 > Project: Apache Jena > Issue Type: Improvement >Affects Versions: Jena 4.3.1 >Reporter: Andy Seaborne >Assignee: Andy Seaborne >Priority: Minor > Fix For: Jena 4.4.0 > > > A single root abstract class for all datasets assemblers would make them > easier to find during development. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JENA-1911) Update Fuseki 2 UI JS code
[ https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463118#comment-17463118 ] Bruno P. Kinoshita commented on JENA-1911: -- Re-opened, updated versions, and marked as resolved. > Update Fuseki 2 UI JS code > -- > > Key: JENA-1911 > URL: https://issues.apache.org/jira/browse/JENA-1911 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 4.3.2 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: Jena 4.4.0 > > Attachments: image-2020-06-05-12-09-57-685.png, > image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, > image-2020-06-05-12-15-19-199.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > The existing Jena Fuseki user interface uses Backbone.js, with extra > libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, > which is largely supported now. > This issue is a placeholder for discussion & work around updating the UI. > Using ES6 in the code would be a great improvement. > But I also suggesting adopting a different framework. The most famous > framework for JS UI is probably React, followed by Angular & Vue. I am using > Vue.js at $work, so I am biased. > The reason we chose Vue.js at work is that the development team is using > mainly Python, with background in Perl, C, and Shell. So out of the three, > Vue.js was the simplest, as it didn't require TypeScript, special syntax, and > the tools required to build an app with Vue are also quite simple. > One downside of this approach is the build of Apache Jena, which would > require Node.js and a build tool like Yarn or NPM. But it also brings > benefits such as: > * We can write unit tests for the UI > * We can write integration (e2e, end to end) tests with Cypress or > Nightwatch (similar to Selenium, but simpler to run and maintain) > * It will be easier to keep the code up to date, as tools like GitHub > security bot are able to inspect package.json and look for outdated or > libraries with CVE's > * It will be easier to incorporate other libraries in the code, so that we > can easily switch the JS code for the editor (for example), or add a new > library to handle SPARQL, etc > * It is now easier to find developers that know Vue, React, Angular, than > Backbone (though that was the first framework I learned, and I really like > it), so maybe we would get more contributors to help with Fuseki UI > So features we would have after this issue: > * Application built with ES6 JavaScript code > * Using Vue.js as framework for the UI > * Adding accessibility support (WCAG 2.0, mybe covering section 508 > though I'm not quite familiar as that's more for US) > * Update all the JS libraries > * Add documentation to the code with JSDoc (the current code lacks > documentation) > * Add tests, both unit and end-to-end (also not present in current code) > * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. > users are already familiar with Fuseki, and know they can upload data, run > queries, etc, so we should make sure that they are able to find it) > * Theming, with a default light-mode, a dark-mode, and (possibly?) > color-blind or other custom themes > * Work on mobile/responsive viewports > * Local browser settings; this is something cheap, that doesn't require > changing to the backend, and would allow us to persist user settings such as: > ** Previous executed Queries > ** Extra query prefixes > ** Number of datasets displayed per page in the main page > ** How long the server status widget queries the server (i.e. should we ping > it every 1 hour? every 30 seconds?) > ** The theme of the user (dark, light, color-blind-protanopia, > high-contrast, etc) leveraging bootstrap-vue > ** User language -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (JENA-1911) Update Fuseki 2 UI JS code
[ https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated JENA-1911: - Fix Version/s: Jena 4.4.0 > Update Fuseki 2 UI JS code > -- > > Key: JENA-1911 > URL: https://issues.apache.org/jira/browse/JENA-1911 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 4.3.2 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: Jena 4.4.0 > > Attachments: image-2020-06-05-12-09-57-685.png, > image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, > image-2020-06-05-12-15-19-199.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > The existing Jena Fuseki user interface uses Backbone.js, with extra > libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, > which is largely supported now. > This issue is a placeholder for discussion & work around updating the UI. > Using ES6 in the code would be a great improvement. > But I also suggesting adopting a different framework. The most famous > framework for JS UI is probably React, followed by Angular & Vue. I am using > Vue.js at $work, so I am biased. > The reason we chose Vue.js at work is that the development team is using > mainly Python, with background in Perl, C, and Shell. So out of the three, > Vue.js was the simplest, as it didn't require TypeScript, special syntax, and > the tools required to build an app with Vue are also quite simple. > One downside of this approach is the build of Apache Jena, which would > require Node.js and a build tool like Yarn or NPM. But it also brings > benefits such as: > * We can write unit tests for the UI > * We can write integration (e2e, end to end) tests with Cypress or > Nightwatch (similar to Selenium, but simpler to run and maintain) > * It will be easier to keep the code up to date, as tools like GitHub > security bot are able to inspect package.json and look for outdated or > libraries with CVE's > * It will be easier to incorporate other libraries in the code, so that we > can easily switch the JS code for the editor (for example), or add a new > library to handle SPARQL, etc > * It is now easier to find developers that know Vue, React, Angular, than > Backbone (though that was the first framework I learned, and I really like > it), so maybe we would get more contributors to help with Fuseki UI > So features we would have after this issue: > * Application built with ES6 JavaScript code > * Using Vue.js as framework for the UI > * Adding accessibility support (WCAG 2.0, mybe covering section 508 > though I'm not quite familiar as that's more for US) > * Update all the JS libraries > * Add documentation to the code with JSDoc (the current code lacks > documentation) > * Add tests, both unit and end-to-end (also not present in current code) > * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. > users are already familiar with Fuseki, and know they can upload data, run > queries, etc, so we should make sure that they are able to find it) > * Theming, with a default light-mode, a dark-mode, and (possibly?) > color-blind or other custom themes > * Work on mobile/responsive viewports > * Local browser settings; this is something cheap, that doesn't require > changing to the backend, and would allow us to persist user settings such as: > ** Previous executed Queries > ** Extra query prefixes > ** Number of datasets displayed per page in the main page > ** How long the server status widget queries the server (i.e. should we ping > it every 1 hour? every 30 seconds?) > ** The theme of the user (dark, light, color-blind-protanopia, > high-contrast, etc) leveraging bootstrap-vue > ** User language -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (JENA-1911) Update Fuseki 2 UI JS code
[ https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated JENA-1911: - Affects Version/s: Jena 4.3.2 (was: Jena 3.15.0) > Update Fuseki 2 UI JS code > -- > > Key: JENA-1911 > URL: https://issues.apache.org/jira/browse/JENA-1911 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 4.3.2 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Attachments: image-2020-06-05-12-09-57-685.png, > image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, > image-2020-06-05-12-15-19-199.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > The existing Jena Fuseki user interface uses Backbone.js, with extra > libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, > which is largely supported now. > This issue is a placeholder for discussion & work around updating the UI. > Using ES6 in the code would be a great improvement. > But I also suggesting adopting a different framework. The most famous > framework for JS UI is probably React, followed by Angular & Vue. I am using > Vue.js at $work, so I am biased. > The reason we chose Vue.js at work is that the development team is using > mainly Python, with background in Perl, C, and Shell. So out of the three, > Vue.js was the simplest, as it didn't require TypeScript, special syntax, and > the tools required to build an app with Vue are also quite simple. > One downside of this approach is the build of Apache Jena, which would > require Node.js and a build tool like Yarn or NPM. But it also brings > benefits such as: > * We can write unit tests for the UI > * We can write integration (e2e, end to end) tests with Cypress or > Nightwatch (similar to Selenium, but simpler to run and maintain) > * It will be easier to keep the code up to date, as tools like GitHub > security bot are able to inspect package.json and look for outdated or > libraries with CVE's > * It will be easier to incorporate other libraries in the code, so that we > can easily switch the JS code for the editor (for example), or add a new > library to handle SPARQL, etc > * It is now easier to find developers that know Vue, React, Angular, than > Backbone (though that was the first framework I learned, and I really like > it), so maybe we would get more contributors to help with Fuseki UI > So features we would have after this issue: > * Application built with ES6 JavaScript code > * Using Vue.js as framework for the UI > * Adding accessibility support (WCAG 2.0, mybe covering section 508 > though I'm not quite familiar as that's more for US) > * Update all the JS libraries > * Add documentation to the code with JSDoc (the current code lacks > documentation) > * Add tests, both unit and end-to-end (also not present in current code) > * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. > users are already familiar with Fuseki, and know they can upload data, run > queries, etc, so we should make sure that they are able to find it) > * Theming, with a default light-mode, a dark-mode, and (possibly?) > color-blind or other custom themes > * Work on mobile/responsive viewports > * Local browser settings; this is something cheap, that doesn't require > changing to the backend, and would allow us to persist user settings such as: > ** Previous executed Queries > ** Extra query prefixes > ** Number of datasets displayed per page in the main page > ** How long the server status widget queries the server (i.e. should we ping > it every 1 hour? every 30 seconds?) > ** The theme of the user (dark, light, color-blind-protanopia, > high-contrast, etc) leveraging bootstrap-vue > ** User language -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (JENA-1911) Update Fuseki 2 UI JS code
[ https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved JENA-1911. -- Resolution: Fixed > Update Fuseki 2 UI JS code > -- > > Key: JENA-1911 > URL: https://issues.apache.org/jira/browse/JENA-1911 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 4.3.2 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: Jena 4.4.0 > > Attachments: image-2020-06-05-12-09-57-685.png, > image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, > image-2020-06-05-12-15-19-199.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > The existing Jena Fuseki user interface uses Backbone.js, with extra > libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, > which is largely supported now. > This issue is a placeholder for discussion & work around updating the UI. > Using ES6 in the code would be a great improvement. > But I also suggesting adopting a different framework. The most famous > framework for JS UI is probably React, followed by Angular & Vue. I am using > Vue.js at $work, so I am biased. > The reason we chose Vue.js at work is that the development team is using > mainly Python, with background in Perl, C, and Shell. So out of the three, > Vue.js was the simplest, as it didn't require TypeScript, special syntax, and > the tools required to build an app with Vue are also quite simple. > One downside of this approach is the build of Apache Jena, which would > require Node.js and a build tool like Yarn or NPM. But it also brings > benefits such as: > * We can write unit tests for the UI > * We can write integration (e2e, end to end) tests with Cypress or > Nightwatch (similar to Selenium, but simpler to run and maintain) > * It will be easier to keep the code up to date, as tools like GitHub > security bot are able to inspect package.json and look for outdated or > libraries with CVE's > * It will be easier to incorporate other libraries in the code, so that we > can easily switch the JS code for the editor (for example), or add a new > library to handle SPARQL, etc > * It is now easier to find developers that know Vue, React, Angular, than > Backbone (though that was the first framework I learned, and I really like > it), so maybe we would get more contributors to help with Fuseki UI > So features we would have after this issue: > * Application built with ES6 JavaScript code > * Using Vue.js as framework for the UI > * Adding accessibility support (WCAG 2.0, mybe covering section 508 > though I'm not quite familiar as that's more for US) > * Update all the JS libraries > * Add documentation to the code with JSDoc (the current code lacks > documentation) > * Add tests, both unit and end-to-end (also not present in current code) > * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. > users are already familiar with Fuseki, and know they can upload data, run > queries, etc, so we should make sure that they are able to find it) > * Theming, with a default light-mode, a dark-mode, and (possibly?) > color-blind or other custom themes > * Work on mobile/responsive viewports > * Local browser settings; this is something cheap, that doesn't require > changing to the backend, and would allow us to persist user settings such as: > ** Previous executed Queries > ** Extra query prefixes > ** Number of datasets displayed per page in the main page > ** How long the server status widget queries the server (i.e. should we ping > it every 1 hour? every 30 seconds?) > ** The theme of the user (dark, light, color-blind-protanopia, > high-contrast, etc) leveraging bootstrap-vue > ** User language -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (JENA-1911) Update Fuseki 2 UI JS code
[ https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita reopened JENA-1911: -- > Update Fuseki 2 UI JS code > -- > > Key: JENA-1911 > URL: https://issues.apache.org/jira/browse/JENA-1911 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.15.0 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Attachments: image-2020-06-05-12-09-57-685.png, > image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, > image-2020-06-05-12-15-19-199.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > The existing Jena Fuseki user interface uses Backbone.js, with extra > libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, > which is largely supported now. > This issue is a placeholder for discussion & work around updating the UI. > Using ES6 in the code would be a great improvement. > But I also suggesting adopting a different framework. The most famous > framework for JS UI is probably React, followed by Angular & Vue. I am using > Vue.js at $work, so I am biased. > The reason we chose Vue.js at work is that the development team is using > mainly Python, with background in Perl, C, and Shell. So out of the three, > Vue.js was the simplest, as it didn't require TypeScript, special syntax, and > the tools required to build an app with Vue are also quite simple. > One downside of this approach is the build of Apache Jena, which would > require Node.js and a build tool like Yarn or NPM. But it also brings > benefits such as: > * We can write unit tests for the UI > * We can write integration (e2e, end to end) tests with Cypress or > Nightwatch (similar to Selenium, but simpler to run and maintain) > * It will be easier to keep the code up to date, as tools like GitHub > security bot are able to inspect package.json and look for outdated or > libraries with CVE's > * It will be easier to incorporate other libraries in the code, so that we > can easily switch the JS code for the editor (for example), or add a new > library to handle SPARQL, etc > * It is now easier to find developers that know Vue, React, Angular, than > Backbone (though that was the first framework I learned, and I really like > it), so maybe we would get more contributors to help with Fuseki UI > So features we would have after this issue: > * Application built with ES6 JavaScript code > * Using Vue.js as framework for the UI > * Adding accessibility support (WCAG 2.0, mybe covering section 508 > though I'm not quite familiar as that's more for US) > * Update all the JS libraries > * Add documentation to the code with JSDoc (the current code lacks > documentation) > * Add tests, both unit and end-to-end (also not present in current code) > * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. > users are already familiar with Fuseki, and know they can upload data, run > queries, etc, so we should make sure that they are able to find it) > * Theming, with a default light-mode, a dark-mode, and (possibly?) > color-blind or other custom themes > * Work on mobile/responsive viewports > * Local browser settings; this is something cheap, that doesn't require > changing to the backend, and would allow us to persist user settings such as: > ** Previous executed Queries > ** Extra query prefixes > ** Number of datasets displayed per page in the main page > ** How long the server status widget queries the server (i.e. should we ping > it every 1 hour? every 30 seconds?) > ** The theme of the user (dark, light, color-blind-protanopia, > high-contrast, etc) leveraging bootstrap-vue > ** User language -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JENA-1911) Update Fuseki 2 UI JS code
[ https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463117#comment-17463117 ] ASF subversion and git services commented on JENA-1911: --- Commit aef75b5486d67e35795677b5dcd584e68f69c939 in jena's branch refs/heads/main from Bruno P. Kinoshita [ https://gitbox.apache.org/repos/asf?p=jena.git;h=aef75b5 ] [JENA-1911] Delete old BackboneJS Fuseki UI > Update Fuseki 2 UI JS code > -- > > Key: JENA-1911 > URL: https://issues.apache.org/jira/browse/JENA-1911 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.15.0 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Attachments: image-2020-06-05-12-09-57-685.png, > image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, > image-2020-06-05-12-15-19-199.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > The existing Jena Fuseki user interface uses Backbone.js, with extra > libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, > which is largely supported now. > This issue is a placeholder for discussion & work around updating the UI. > Using ES6 in the code would be a great improvement. > But I also suggesting adopting a different framework. The most famous > framework for JS UI is probably React, followed by Angular & Vue. I am using > Vue.js at $work, so I am biased. > The reason we chose Vue.js at work is that the development team is using > mainly Python, with background in Perl, C, and Shell. So out of the three, > Vue.js was the simplest, as it didn't require TypeScript, special syntax, and > the tools required to build an app with Vue are also quite simple. > One downside of this approach is the build of Apache Jena, which would > require Node.js and a build tool like Yarn or NPM. But it also brings > benefits such as: > * We can write unit tests for the UI > * We can write integration (e2e, end to end) tests with Cypress or > Nightwatch (similar to Selenium, but simpler to run and maintain) > * It will be easier to keep the code up to date, as tools like GitHub > security bot are able to inspect package.json and look for outdated or > libraries with CVE's > * It will be easier to incorporate other libraries in the code, so that we > can easily switch the JS code for the editor (for example), or add a new > library to handle SPARQL, etc > * It is now easier to find developers that know Vue, React, Angular, than > Backbone (though that was the first framework I learned, and I really like > it), so maybe we would get more contributors to help with Fuseki UI > So features we would have after this issue: > * Application built with ES6 JavaScript code > * Using Vue.js as framework for the UI > * Adding accessibility support (WCAG 2.0, mybe covering section 508 > though I'm not quite familiar as that's more for US) > * Update all the JS libraries > * Add documentation to the code with JSDoc (the current code lacks > documentation) > * Add tests, both unit and end-to-end (also not present in current code) > * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. > users are already familiar with Fuseki, and know they can upload data, run > queries, etc, so we should make sure that they are able to find it) > * Theming, with a default light-mode, a dark-mode, and (possibly?) > color-blind or other custom themes > * Work on mobile/responsive viewports > * Local browser settings; this is something cheap, that doesn't require > changing to the backend, and would allow us to persist user settings such as: > ** Previous executed Queries > ** Extra query prefixes > ** Number of datasets displayed per page in the main page > ** How long the server status widget queries the server (i.e. should we ping > it every 1 hour? every 30 seconds?) > ** The theme of the user (dark, light, color-blind-protanopia, > high-contrast, etc) leveraging bootstrap-vue > ** User language -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JENA-1911) Update Fuseki 2 UI JS code
[ https://issues.apache.org/jira/browse/JENA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463116#comment-17463116 ] ASF subversion and git services commented on JENA-1911: --- Commit 78e002107b3f7494bd1d1260c47d1df5629a1ee7 in jena's branch refs/heads/main from Bruno P. Kinoshita [ https://gitbox.apache.org/repos/asf?p=jena.git;h=78e0021 ] [JENA-1911] New UI This commit replaces the old BackboneJS by Vue.JS, using the Vue CLI utility and npm to build this new Maven module. It also uses a Maven build plug-in to invoke NPM. License and Notice files were updated, as well as the build settings to generate these files. Other changes include modifications to the jena-fuseki-webapp module on how it loads the UI files, and other minor changes required to have the new UI (e.g. ignore YARN/NPM files in RAT). See JENA-1911 and the two pull requests created for this change for more. > Update Fuseki 2 UI JS code > -- > > Key: JENA-1911 > URL: https://issues.apache.org/jira/browse/JENA-1911 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Jena 3.15.0 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Attachments: image-2020-06-05-12-09-57-685.png, > image-2020-06-05-12-11-01-945.png, image-2020-06-05-12-13-40-428.png, > image-2020-06-05-12-15-19-199.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > The existing Jena Fuseki user interface uses Backbone.js, with extra > libraries such as JQuery, Marionette.js. The JavaScript code pre-dates ES6, > which is largely supported now. > This issue is a placeholder for discussion & work around updating the UI. > Using ES6 in the code would be a great improvement. > But I also suggesting adopting a different framework. The most famous > framework for JS UI is probably React, followed by Angular & Vue. I am using > Vue.js at $work, so I am biased. > The reason we chose Vue.js at work is that the development team is using > mainly Python, with background in Perl, C, and Shell. So out of the three, > Vue.js was the simplest, as it didn't require TypeScript, special syntax, and > the tools required to build an app with Vue are also quite simple. > One downside of this approach is the build of Apache Jena, which would > require Node.js and a build tool like Yarn or NPM. But it also brings > benefits such as: > * We can write unit tests for the UI > * We can write integration (e2e, end to end) tests with Cypress or > Nightwatch (similar to Selenium, but simpler to run and maintain) > * It will be easier to keep the code up to date, as tools like GitHub > security bot are able to inspect package.json and look for outdated or > libraries with CVE's > * It will be easier to incorporate other libraries in the code, so that we > can easily switch the JS code for the editor (for example), or add a new > library to handle SPARQL, etc > * It is now easier to find developers that know Vue, React, Angular, than > Backbone (though that was the first framework I learned, and I really like > it), so maybe we would get more contributors to help with Fuseki UI > So features we would have after this issue: > * Application built with ES6 JavaScript code > * Using Vue.js as framework for the UI > * Adding accessibility support (WCAG 2.0, mybe covering section 508 > though I'm not quite familiar as that's more for US) > * Update all the JS libraries > * Add documentation to the code with JSDoc (the current code lacks > documentation) > * Add tests, both unit and end-to-end (also not present in current code) > * Maintain the look and feel with Bootstrap, and limit what is changed (i.e. > users are already familiar with Fuseki, and know they can upload data, run > queries, etc, so we should make sure that they are able to find it) > * Theming, with a default light-mode, a dark-mode, and (possibly?) > color-blind or other custom themes > * Work on mobile/responsive viewports > * Local browser settings; this is something cheap, that doesn't require > changing to the backend, and would allow us to persist user settings such as: > ** Previous executed Queries > ** Extra query prefixes > ** Number of datasets displayed per page in the main page > ** How long the server status widget queries the server (i.e. should we ping > it every 1 hour? every 30 seconds?) > ** The theme of the user (dark, light, color-blind-protanopia, > high-contrast, etc) leveraging bootstrap-vue > ** User language -- This message was sent by Atlassian Jira (v8.20.1#820001)
Re: Testing tdb2.xloader
Thank you Andy. found it in revisions somewhere
just finished another run with truthy
http://lotico.com/temp/LOG-1214
will now increase RAM before running an additional load with increased
thread count.
Marco
On Tue, Dec 21, 2021 at 8:48 AM Andy Seaborne wrote:
> gists are git repos: so the file is there ... somewhere:
>
>
> https://gist.githubusercontent.com/LorenzBuehmann/e3619d53cf4c158c4e4902fd7d6ed7c3/raw/9049cf8b559ce685b4293fca10d8b1c07cc79c43/tdb2_xloader_wikidata_truthy.log
>
> Andy
>
> On 19/12/2021 17:56, Marco Neumann wrote:
> > Thank you Lorenz,
> > unfortunately the tdb2_xloader_wikidata_truthy.log is now truncated in
> > github
> >
> >
> > On Sun, Dec 19, 2021 at 9:46 AM LB
> > wrote:
> >
> >> I edited the Gist [1] and put the default stats there. Takes ~4min to
> >> compute the stats.
> >>
> >> Findings:
> >>
> >> - for Wikidata we have to extend those stats with the stats for wdt:P31
> >> property as Wikidata does use this property as their own rdf:type
> >> relation. It is indeed trivial, just execute
> >>
> >> select ?c (count(*) as ?cnt) {?s
> >> ?c} group by ?c
> >>
> >> and convert it into the stats rule language (SSE) and put those rules
> >> before the more generic rule
> >>
> >> |( 98152611)|
> >>
> >> - I didn't want to touch the stats script itself, but we could for
> >> example also make this type relation generic and allow for other like
> >> wdt:P31 or skos:subject via a commandline option which provides any URI
> >> as the type relation with default being rdf:type - but that's for sure
> >> probably overkill
> >>
> >> - there is a bug in the stats script or file I guess, because of of some
> >> overflow? the count value is
> >>
> >> (count -1983667112))
> >>
> >> which indicates this. I opened a ticket:
> >> https://issues.apache.org/jira/browse/JENA-2225
> >>
> >>
> >> [1]
> >> https://gist.github.com/LorenzBuehmann/e3619d53cf4c158c4e4902fd7d6ed7c3
> >>
> >> On 18.12.21 11:35, Marco Neumann wrote:
> >>> good morning Lorenz,
> >>>
> >>> Maybe time to get a few query bencharms tests? :)
> >>>
> >>> What does tdb2.tdbstats report?
> >>>
> >>> Marco
> >>>
> >>>
> >>> On Sat, Dec 18, 2021 at 8:09 AM LB .invalid>
> >>> wrote:
> >>>
> Good morning,
>
> loading of Wikidata truthy is done, this time I didn't forget to keep
> logs:
>
> https://gist.github.com/LorenzBuehmann/e3619d53cf4c158c4e4902fd7d6ed7c3
>
> I'm a bit surprised that this time it was 8h faster than last time,
> 31h
> vs 39h. Not sure if a) there was something else on the server last
> time
> (at least I couldn't see any running tasks) or b) if this is a
> consequence of the more parallelized Unix sort now - I set it to
> --parallel=16
>
> I mean, the piped input stream is single threaded I guess, but maybe
> the
> sort merge step can benefit from more threads? I guess I have to clean
> up everything and run it again with the original setup with 2 Unix
> sort
> threads ...
>
>
> On 16.12.21 14:48, Andy Seaborne wrote:
> >
> > On 16/12/2021 10:52, Andy Seaborne wrote:
> > ...
> >
> >> I am getting a slow down during data ingestion. However, your
> summary
> >> figures don't show that in the ingest phase. The whole logs may have
> >> the signal in it but less pronounced.
> >>
> >> My working assumption is now that it is random access to the node
> >> table. Your results point to it not being a CPU issue but that my
> >> setup is saturating the I/O path. While the portable has a NVMe SSD,
> >> it has probably not got the same I/O bandwidth as a server class
> >> machine.
> >>
> >> I'm not sure what to do about this other than run with a much bigger
> >> node table cache for the ingestion phase. Substituting some file
> >> mapper file area for bigger cache should be a win. While I hadn't
> >> noticed before, it is probably visible in logs of smaller loads on
> >> closer inspection. Experimenting on a small dataset is a lot easier.
> > I'm more sure of this - not yet definite.
> >
> > The nodeToNodeId cache is 200k -- this is on the load/update path.
> > Seems rather small for the task.
> >
> > The nodeIdToNode cache is 1e6 -- this is the one that is hit by
> SPARQL
> > results.
> >
> > 2 pieces of data will help:
> >
> > Experimenting with very small cache settings.
> >
> > Letting my slow load keep going to see if there is the same
> > characteristics at the index stage. There shouldn't be if
> nodeToNodeId
> > is the cause; it's only an influence in the data ingestion step.
> >
> > Aside : Increasing nodeToNodeId could also help tdbloader=parallel
> and
> > maybe loader=phased. It falls into the same situation although the
> > improvement there is going to be less marked.
Re: Testing tdb2.xloader
gists are git repos: so the file is there ... somewhere:
https://gist.githubusercontent.com/LorenzBuehmann/e3619d53cf4c158c4e4902fd7d6ed7c3/raw/9049cf8b559ce685b4293fca10d8b1c07cc79c43/tdb2_xloader_wikidata_truthy.log
Andy
On 19/12/2021 17:56, Marco Neumann wrote:
Thank you Lorenz,
unfortunately the tdb2_xloader_wikidata_truthy.log is now truncated in
github
On Sun, Dec 19, 2021 at 9:46 AM LB
wrote:
I edited the Gist [1] and put the default stats there. Takes ~4min to
compute the stats.
Findings:
- for Wikidata we have to extend those stats with the stats for wdt:P31
property as Wikidata does use this property as their own rdf:type
relation. It is indeed trivial, just execute
select ?c (count(*) as ?cnt) {?s
?c} group by ?c
and convert it into the stats rule language (SSE) and put those rules
before the more generic rule
|( 98152611)|
- I didn't want to touch the stats script itself, but we could for
example also make this type relation generic and allow for other like
wdt:P31 or skos:subject via a commandline option which provides any URI
as the type relation with default being rdf:type - but that's for sure
probably overkill
- there is a bug in the stats script or file I guess, because of of some
overflow? the count value is
(count -1983667112))
which indicates this. I opened a ticket:
https://issues.apache.org/jira/browse/JENA-2225
[1]
https://gist.github.com/LorenzBuehmann/e3619d53cf4c158c4e4902fd7d6ed7c3
On 18.12.21 11:35, Marco Neumann wrote:
good morning Lorenz,
Maybe time to get a few query bencharms tests? :)
What does tdb2.tdbstats report?
Marco
On Sat, Dec 18, 2021 at 8:09 AM LB
wrote:
Good morning,
loading of Wikidata truthy is done, this time I didn't forget to keep
logs:
https://gist.github.com/LorenzBuehmann/e3619d53cf4c158c4e4902fd7d6ed7c3
I'm a bit surprised that this time it was 8h faster than last time, 31h
vs 39h. Not sure if a) there was something else on the server last time
(at least I couldn't see any running tasks) or b) if this is a
consequence of the more parallelized Unix sort now - I set it to
--parallel=16
I mean, the piped input stream is single threaded I guess, but maybe the
sort merge step can benefit from more threads? I guess I have to clean
up everything and run it again with the original setup with 2 Unix sort
threads ...
On 16.12.21 14:48, Andy Seaborne wrote:
On 16/12/2021 10:52, Andy Seaborne wrote:
...
I am getting a slow down during data ingestion. However, your summary
figures don't show that in the ingest phase. The whole logs may have
the signal in it but less pronounced.
My working assumption is now that it is random access to the node
table. Your results point to it not being a CPU issue but that my
setup is saturating the I/O path. While the portable has a NVMe SSD,
it has probably not got the same I/O bandwidth as a server class
machine.
I'm not sure what to do about this other than run with a much bigger
node table cache for the ingestion phase. Substituting some file
mapper file area for bigger cache should be a win. While I hadn't
noticed before, it is probably visible in logs of smaller loads on
closer inspection. Experimenting on a small dataset is a lot easier.
I'm more sure of this - not yet definite.
The nodeToNodeId cache is 200k -- this is on the load/update path.
Seems rather small for the task.
The nodeIdToNode cache is 1e6 -- this is the one that is hit by SPARQL
results.
2 pieces of data will help:
Experimenting with very small cache settings.
Letting my slow load keep going to see if there is the same
characteristics at the index stage. There shouldn't be if nodeToNodeId
is the cause; it's only an influence in the data ingestion step.
Aside : Increasing nodeToNodeId could also help tdbloader=parallel and
maybe loader=phased. It falls into the same situation although the
improvement there is going to be less marked. "Parallel" saturates the
I/O by other means as well.
Andy
