[jira] [Commented] (JENA-1434) Allow warnings to be treated as errors by RIOT
[
https://issues.apache.org/jira/browse/JENA-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16269492#comment-16269492
]
Ian Dickinson commented on JENA-1434:
-
Thanks all!
Ian
> Allow warnings to be treated as errors by RIOT
> --
>
> Key: JENA-1434
> URL: https://issues.apache.org/jira/browse/JENA-1434
> Project: Apache Jena
> Issue Type: Improvement
> Components: RIOT
>Affects Versions: Jena 3.5.0
>Reporter: Ian Dickinson
>Assignee: Rob Vesse
> Fix For: Jena 3.6.0
>
>
> I would like to use `riot --validate` as part of an integration test for a
> system that generates Turtle. Ideally, the exit status for the riot command
> would be non-zero, indicating a problem, if the input was not valid. However,
> I see an exit status of zero always:
> {noformat}
> $ riot --validate alert.ttl && echo 'exit status is: ' $?
> 13:50:37 WARN riot :: [line: 39, col: 25] Lexical form
> '2017-03-19T00:00:00+00:00' not valid for datatype XSD date
> 13:50:37 WARN riot :: [line: 42, col: 20] Lexical form ''
> not valid for datatype XSD date
> 13:50:37 WARN riot :: [line: 58, col: 20] Lexical form ''
> not valid for datatype XSD date
> exit status is: 0
> {noformat}
> Version info:
> {noformat}
> $ riot --version
> Jena: VERSION: 3.5.0
> Jena: BUILD_DATE: 2017-10-30T09:20:28+
> RIOT: VERSION: 3.5.0
> RIOT: BUILD_DATE: 2017-10-30T09:20:28+
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JENA-1434) Set exit status code when riot is running in --validate mode
[
https://issues.apache.org/jira/browse/JENA-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16264497#comment-16264497
]
Ian Dickinson commented on JENA-1434:
-
Thanks Rob. It appears that `--stop` only works for error, not warnings:
{noformat}
ian@ian-desktop $ riot --validate --stop temp/alert.ttl
15:49:12 WARN riot :: [line: 39, col: 25] Lexical form
'2017-03-19T00:00:00+00:00' not valid for datatype XSD date
15:49:12 WARN riot :: [line: 42, col: 20] Lexical form '' not
valid for datatype XSD date
15:49:12 WARN riot :: [line: 47, col: 25] Lexical form
'2017-11-19T00:00:00+00:00' not valid for datatype XSD date
15:49:12 WARN riot :: [line: 50, col: 20] Lexical form '' not
valid for datatype XSD date
15:49:12 WARN riot :: [line: 55, col: 25] Lexical form
'2017-02-20T00:00:00+00:00' not valid for datatype XSD date
15:49:12 WARN riot :: [line: 58, col: 20] Lexical form '' not
valid for datatype XSD date
ian@ian-desktop $ echo $?
0
{noformat}
I would still argue that, when you specifically ask for validation with
--validate, a non-zero termination status is warranted even for warnings.
Different status values could be used for warnings and for errors.
> Set exit status code when riot is running in --validate mode
>
>
> Key: JENA-1434
> URL: https://issues.apache.org/jira/browse/JENA-1434
> Project: Apache Jena
> Issue Type: Improvement
> Components: RIOT
>Affects Versions: Jena 3.5.0
>Reporter: Ian Dickinson
>Assignee: Rob Vesse
>
> I would like to use `riot --validate` as part of an integration test for a
> system that generates Turtle. Ideally, the exit status for the riot command
> would be non-zero, indicating a problem, if the input was not valid. However,
> I see an exit status of zero always:
> {noformat}
> $ riot --validate alert.ttl && echo 'exit status is: ' $?
> 13:50:37 WARN riot :: [line: 39, col: 25] Lexical form
> '2017-03-19T00:00:00+00:00' not valid for datatype XSD date
> 13:50:37 WARN riot :: [line: 42, col: 20] Lexical form ''
> not valid for datatype XSD date
> 13:50:37 WARN riot :: [line: 58, col: 20] Lexical form ''
> not valid for datatype XSD date
> exit status is: 0
> {noformat}
> Version info:
> {noformat}
> $ riot --version
> Jena: VERSION: 3.5.0
> Jena: BUILD_DATE: 2017-10-30T09:20:28+
> RIOT: VERSION: 3.5.0
> RIOT: BUILD_DATE: 2017-10-30T09:20:28+
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JENA-1434) Set exit status code when riot is running in --validate mode
Ian Dickinson created JENA-1434:
---
Summary: Set exit status code when riot is running in --validate
mode
Key: JENA-1434
URL: https://issues.apache.org/jira/browse/JENA-1434
Project: Apache Jena
Issue Type: Improvement
Components: RIOT
Affects Versions: Jena 3.5.0
Reporter: Ian Dickinson
I would like to use `riot --validate` as part of an integration test for a
system that generates Turtle. Ideally, the exit status for the riot command
would be non-zero, indicating a problem, if the input was not valid. However, I
see an exit status of zero always:
{noformat}
$ riot --validate alert.ttl && echo 'exit status is: ' $?
13:50:37 WARN riot :: [line: 39, col: 25] Lexical form
'2017-03-19T00:00:00+00:00' not valid for datatype XSD date
13:50:37 WARN riot :: [line: 42, col: 20] Lexical form '' not
valid for datatype XSD date
13:50:37 WARN riot :: [line: 58, col: 20] Lexical form '' not
valid for datatype XSD date
exit status is: 0
{noformat}
Version info:
{noformat}
$ riot --version
Jena: VERSION: 3.5.0
Jena: BUILD_DATE: 2017-10-30T09:20:28+
RIOT: VERSION: 3.5.0
RIOT: BUILD_DATE: 2017-10-30T09:20:28+
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349638#comment-14349638 ] Ian Dickinson commented on JENA-890: That's an interesting take, thanks. I wonder if it's worth us taking a step back and thinking about what the goal for Fuseki is, or could be(come). And probably doing it on dev@, rather than on this issue thread! Fwiw, my instinct is to keep focussed on a simple interface that does a good job of managing datasets. Some level of query is a natural part of that process - after I've loaded data, I may want to inspect it to make sure I've done my job correctly. But (imho) what the user of this Fuseki cares about is effectively managing data: loading, monitoring, backing up, performance testing, and security, and doing that effectively, simply and reliably. An alternative view is that Fuseki is an 'out-of-the-box' tool to help get people going on their RDF/linked-data journey. These users problaby don't care so much about managing complex collections of datasets, but want a one-stop shop to load, query and explore their data. Another view is that serious production users want all of the basic management capability, plus the tools to diagnose queries that don't work as expected, monitor usage patterns, etc. Or another is that Fuseki is a 'lite' BI tool for RDF and linked data: load your data, and generate reports and dataviz that allow you to explore data and discover its value. And doubtless many others. It isn't that any one of these is undesirable - I've had situations where I would have loved every capability on the above list. To me, it's at least in-part, a question of keeping focus and avoiding creeping bloatware. One tool *could* do all this and more, but I think that tool would become fat, complex, hard to maintain and harder to use. Treading the Protege path, for example, is something I would want to avoid. > Pivot table in Fuseki2 has confusing design and user experience > --- > > Key: JENA-890 > URL: https://issues.apache.org/jira/browse/JENA-890 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Fuseki 2.0.0 >Reporter: Ian Dickinson > > The SPARQL query tab on the Fuseki2 interface has an option in the results > pane labelled 'pivot table'. It's very, very unclear what this does. It > appears to be an experimental feature of some kind, but it does not provide a > clear, discoverable user experience. In fact, after playing with it for some > minutes, I still can't figure out what it is actually for. > I suggest that either the UX of this feature is radically improved, or we > remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349611#comment-14349611 ] Ian Dickinson commented on JENA-890: I'm going to ignore your absurd straw man argument, except to note that it's not an effective way to participate in a collaborative discussion. I'm happy to have a reasoned discussion; I don't care about bluster. To the actual point: it doesn't really matter whether you spent 45 seconds or 45 minutes writing a paragraph of explanatory text - people in general won't read it. There's plenty of research to back that up. Here's a sample: http://www.nngroup.com/articles/satisficing/ http://www.nngroup.com/articles/how-users-read-on-the-web/ http://www.uxbooth.com/articles/10-usability-lessons-from-steve-krugs-dont-make-me-think/ notes 1-3 http://guidelines.usability.gov/guidelines/172 > Pivot table in Fuseki2 has confusing design and user experience > --- > > Key: JENA-890 > URL: https://issues.apache.org/jira/browse/JENA-890 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Fuseki 2.0.0 >Reporter: Ian Dickinson > > The SPARQL query tab on the Fuseki2 interface has an option in the results > pane labelled 'pivot table'. It's very, very unclear what this does. It > appears to be an experimental feature of some kind, but it does not provide a > clear, discoverable user experience. In fact, after playing with it for some > minutes, I still can't figure out what it is actually for. > I suggest that either the UX of this feature is radically improved, or we > remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14347937#comment-14347937 ] Ian Dickinson commented on JENA-890: That's a remarkable example of a "simple" instruction text. I'm afraid I stick to my point. Pivot tables have their place, no doubt, but it's far from clear to me that the base dataset management tool is that place. And surely anyone who requires the full capability of Yasr can just run their own Yasgui instance, no? > Pivot table in Fuseki2 has confusing design and user experience > --- > > Key: JENA-890 > URL: https://issues.apache.org/jira/browse/JENA-890 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Fuseki 2.0.0 >Reporter: Ian Dickinson > > The SPARQL query tab on the Fuseki2 interface has an option in the results > pane labelled 'pivot table'. It's very, very unclear what this does. It > appears to be an experimental feature of some kind, but it does not provide a > clear, discoverable user experience. In fact, after playing with it for some > minutes, I still can't figure out what it is actually for. > I suggest that either the UX of this feature is radically improved, or we > remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345394#comment-14345394 ] Ian Dickinson commented on JENA-890: > (is this blocker for the release?) Do you mean "a blocker" or "the blocker"? There are a number of problems with the recent clutch of changes to Fuseki2 - I'm working on fixing them but I'm also very busy with client work. I'll start a separate thread on dev@ to discuss. > Pivot table in Fuseki2 has confusing design and user experience > --- > > Key: JENA-890 > URL: https://issues.apache.org/jira/browse/JENA-890 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Fuseki 2.0.0 >Reporter: Ian Dickinson > > The SPARQL query tab on the Fuseki2 interface has an option in the results > pane labelled 'pivot table'. It's very, very unclear what this does. It > appears to be an experimental feature of some kind, but it does not provide a > clear, discoverable user experience. In fact, after playing with it for some > minutes, I still can't figure out what it is actually for. > I suggest that either the UX of this feature is radically improved, or we > remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345385#comment-14345385 ] Ian Dickinson commented on JENA-890: Happy to feed back comments to upstream. The pivot table isn't the only problem with Yasgui, but it is the worst. > Pivot table in Fuseki2 has confusing design and user experience > --- > > Key: JENA-890 > URL: https://issues.apache.org/jira/browse/JENA-890 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Fuseki 2.0.0 >Reporter: Ian Dickinson > > The SPARQL query tab on the Fuseki2 interface has an option in the results > pane labelled 'pivot table'. It's very, very unclear what this does. It > appears to be an experimental feature of some kind, but it does not provide a > clear, discoverable user experience. In fact, after playing with it for some > minutes, I still can't figure out what it is actually for. > I suggest that either the UX of this feature is radically improved, or we > remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345384#comment-14345384 ] Ian Dickinson commented on JENA-890: Sorry, but what's the use case for having analysis and charting tools in Fuseki at all? I totally get that such things can be useful for some users in some contexts, and I'm all for people experimenting with RDF-based dataviz workbenches, but Fuseki is a dataset control and publishing UI. It should, in my opinion, be focussed on doing that task well. I'm not, in general, in favour of adding user-configurable options to UI's. I strongly recommend Steve Krug's book on this topic (http://www.amazon.co.uk/Dont-Make-Me-Think-Usability/dp/0321965515/ref=asap_bc?ie=UTF8). Whenever as a developer you put a user configuration option in a UI, you're doubling the test surface of the system, but moreover you're making the user do the hard work of figuring out what the right behaviour should be for you. > Pivot table in Fuseki2 has confusing design and user experience > --- > > Key: JENA-890 > URL: https://issues.apache.org/jira/browse/JENA-890 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Fuseki 2.0.0 >Reporter: Ian Dickinson > > The SPARQL query tab on the Fuseki2 interface has an option in the results > pane labelled 'pivot table'. It's very, very unclear what this does. It > appears to be an experimental feature of some kind, but it does not provide a > clear, discoverable user experience. In fact, after playing with it for some > minutes, I still can't figure out what it is actually for. > I suggest that either the UX of this feature is radically improved, or we > remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
[ https://issues.apache.org/jira/browse/JENA-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344687#comment-14344687 ] Ian Dickinson commented on JENA-890: > anecdotally I figured it out in a couple of minutes That, right there, is a perfect illustration of a non-discoverable user interface. If it takes the user several minutes to figure out, and is easier with prior experience of a reference tool that itself is quite complex, then clearly it's not aimed at the general user. Fuseki is not an RDF analysis and charting tool. That's a great thing for someone to develop, but it's a separate research and development activity. Fuseki should simply do a good job of providing a UI for people to manage the serving of RDF data via HTTP. > Pivot table in Fuseki2 has confusing design and user experience > --- > > Key: JENA-890 > URL: https://issues.apache.org/jira/browse/JENA-890 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Affects Versions: Fuseki 2.0.0 >Reporter: Ian Dickinson > > The SPARQL query tab on the Fuseki2 interface has an option in the results > pane labelled 'pivot table'. It's very, very unclear what this does. It > appears to be an experimental feature of some kind, but it does not provide a > clear, discoverable user experience. In fact, after playing with it for some > minutes, I still can't figure out what it is actually for. > I suggest that either the UX of this feature is radically improved, or we > remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JENA-890) Pivot table in Fuseki2 has confusing design and user experience
Ian Dickinson created JENA-890: -- Summary: Pivot table in Fuseki2 has confusing design and user experience Key: JENA-890 URL: https://issues.apache.org/jira/browse/JENA-890 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 2.0.0 Reporter: Ian Dickinson The SPARQL query tab on the Fuseki2 interface has an option in the results pane labelled 'pivot table'. It's very, very unclear what this does. It appears to be an experimental feature of some kind, but it does not provide a clear, discoverable user experience. In fact, after playing with it for some minutes, I still can't figure out what it is actually for. I suggest that either the UX of this feature is radically improved, or we remove it from Fuseki2 until it is ready for wider exposure. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-849) Incorrect version numbers in schemagen maven documentation
[
https://issues.apache.org/jira/browse/JENA-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14276739#comment-14276739
]
Ian Dickinson commented on JENA-849:
Good point, Rob, thanks. The original reporter was also noting that the
artifact and groupId names have changed, and these are more stable.
Is there a page where we list the current versions of the various Jena maven
artifacts, that we could point to from this page, and others that tell users
about maven configuration?
> Incorrect version numbers in schemagen maven documentation
> --
>
> Key: JENA-849
> URL: https://issues.apache.org/jira/browse/JENA-849
> Project: Apache Jena
> Issue Type: Documentation
> Components: Maven Tools
>Affects Versions: Jena 2.12.1
>Reporter: Ian Dickinson
>Priority: Minor
>
> Reported by Alexander Willner.
> Documentation for the Schemagen maven plugin has the wrong maven config: it
> says
> {code:xml}
>
> org.apache.jena.tools
> schemagen
> 0.2-SNAPSHOT
> maven-plugin
>
> {code}
> it should say:
> {code:xml}
>
> org.apache.jena
> jena-maven-tools
> 0.7
> maven-plugin
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JENA-849) Incorrect version numbers in schemagen maven documentation
[
https://issues.apache.org/jira/browse/JENA-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Dickinson updated JENA-849:
---
Description:
Reported by Alexander Willner.
Documentation for the Schemagen maven plugin has the wrong maven config: it says
{code:xml}
org.apache.jena.tools
schemagen
0.2-SNAPSHOT
maven-plugin
{code}
it should say:
{code:xml}
org.apache.jena
jena-maven-tools
0.7
maven-plugin
{code}
was:
Reported by Alexander Willner.
Documentation for the Schemagen maven plugin has the wrong maven config: it says
org.apache.jena.tools
schemagen
0.2-SNAPSHOT
maven-plugin
it should say:
org.apache.jena
jena-maven-tools
0.7
maven-plugin
> Incorrect version numbers in schemagen maven documentation
> --
>
> Key: JENA-849
> URL: https://issues.apache.org/jira/browse/JENA-849
> Project: Apache Jena
> Issue Type: Documentation
> Components: Maven Tools
>Affects Versions: Jena 2.12.1
>Reporter: Ian Dickinson
>Priority: Minor
>
> Reported by Alexander Willner.
> Documentation for the Schemagen maven plugin has the wrong maven config: it
> says
> {code:xml}
>
> org.apache.jena.tools
> schemagen
> 0.2-SNAPSHOT
> maven-plugin
>
> {code}
> it should say:
> {code:xml}
>
> org.apache.jena
> jena-maven-tools
> 0.7
> maven-plugin
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JENA-849) Incorrect version numbers in schemagen maven documentation
Ian Dickinson created JENA-849: -- Summary: Incorrect version numbers in schemagen maven documentation Key: JENA-849 URL: https://issues.apache.org/jira/browse/JENA-849 Project: Apache Jena Issue Type: Documentation Components: Maven Tools Affects Versions: Jena 2.12.1 Reporter: Ian Dickinson Priority: Minor Reported by Alexander Willner. Documentation for the Schemagen maven plugin has the wrong maven config: it says org.apache.jena.tools schemagen 0.2-SNAPSHOT maven-plugin it should say: org.apache.jena jena-maven-tools 0.7 maven-plugin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JENA-737) Deleting a dataset has stopped working
[
https://issues.apache.org/jira/browse/JENA-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051529#comment-14051529
]
Ian Dickinson commented on JENA-737:
Hi Rob,
I think one of the things we have yet to discover is the right balance between
convenience and protecting users from themselves. Yes delete could be a one-way
street to "er, I probably didn't mean that"-ville, but there are lots of other
side-effecting operations: uploading a file to a dataset, editing the contents
of a graph, etc. In principle (though afaik this isn't working at the moment),
the Qonsole should allow people to run SPARQL update commands. I'm loathe to
turn off-by-default every action that could potentially do something that
someone might regret, but which other people would find useful.
You're absolutely right that the intent is that Shiro will be the way to
control who gets to do which operations. That part of Fuseki2 is - at best -
underdeveloped at the moment! We could do with some solid user stories to
design and test against.
For the time being, I propose that we leave the (potentially) dangerous
operations enabled, and get some experience/user feedback. And figure out how
the Shiro stuff would work out in practice!
Another thing to think about - no advocacy, just an idea - would be to have
development and production modes like a Rails server.
> Deleting a dataset has stopped working
> --
>
> Key: JENA-737
> URL: https://issues.apache.org/jira/browse/JENA-737
> Project: Apache Jena
> Issue Type: Bug
> Components: Fuseki
>Reporter: Ian Dickinson
>Assignee: Andy Seaborne
>Priority: Minor
> Labels: fuseki2
>
> Deleting a dataset using the HTTP DELETE verb isn't working (or I've got it
> wrong). I think the following sequence used to work in Fuseki2, but now is
> returning a 400 error:
> {noformat}
> $ curl http://localhost:3030/$/datasets/foo
> {
> "ds.name" : "/foo" ,
> "ds.services" : [
> {
> "srv.description" : "Graph Store Protocol (Read)" ,
> "srv.endpoints" : [ "get" ] ,
> "srv.type" : "GSP_R"
> } ,
> {
> "srv.description" : "HTTP Quads" ,
> "srv.endpoints" : [ "" ] ,
> "srv.type" : "Quads"
> } ,
> {
> "srv.description" : "Graph Store Protocol" ,
> "srv.endpoints" : [ "data" ] ,
> "srv.type" : "GSP"
> } ,
> {
> "srv.description" : "SPARQL Update" ,
> "srv.endpoints" : [ "update" ] ,
> "srv.type" : "Update"
> } ,
> {
> "srv.description" : "SPARQL Query" ,
> "srv.endpoints" : [
> "sparql" ,
> "query"
> ] ,
> "srv.type" : "Query"
> } ,
> {
> "srv.description" : "File Upload" ,
> "srv.endpoints" : [ "upload" ] ,
> "srv.type" : "Upload"
> }
> ] ,
> "ds.state" : true
> }
> [~/workspace/jena-fuseki2]
> ian@ian-desktop $ curl -XDELETE -v http://localhost:3030/$/datasets/foo
> * Hostname was NOT found in DNS cache
> * Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 3030 (#0)
> > DELETE /$/datasets/foo HTTP/1.1
> > User-Agent: curl/7.35.0
> > Host: localhost:3030
> > Accept: */*
> >
> < HTTP/1.1 400 Failed to find dataset for '/foo'
> < Fuseki-Request-ID: 224
> < Access-Control-Allow-Origin: *
> * Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
> < Server: Fuseki (2.0.0.M2-SNAPSHOT)
> < Content-Length: 0
> <
> * Connection #0 to host localhost left intact
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JENA-737) Deleting a dataset has stopped working
[
https://issues.apache.org/jira/browse/JENA-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051456#comment-14051456
]
Ian Dickinson commented on JENA-737:
{quote}
How did the dataset get created? UI? Command line? Static config file?
{quote}
In this case, it was an in-memory dataset created via the UI (by POSTing to
{{/$/datasets}}) but I can see that the general case is potentially tricky.
I can easily disable the delete action for the first release, if that's the
best thing to do.
> Deleting a dataset has stopped working
> --
>
> Key: JENA-737
> URL: https://issues.apache.org/jira/browse/JENA-737
> Project: Apache Jena
> Issue Type: Bug
> Components: Fuseki
>Reporter: Ian Dickinson
>Assignee: Andy Seaborne
>Priority: Minor
> Labels: fuseki2
>
> Deleting a dataset using the HTTP DELETE verb isn't working (or I've got it
> wrong). I think the following sequence used to work in Fuseki2, but now is
> returning a 400 error:
> {noformat}
> $ curl http://localhost:3030/$/datasets/foo
> {
> "ds.name" : "/foo" ,
> "ds.services" : [
> {
> "srv.description" : "Graph Store Protocol (Read)" ,
> "srv.endpoints" : [ "get" ] ,
> "srv.type" : "GSP_R"
> } ,
> {
> "srv.description" : "HTTP Quads" ,
> "srv.endpoints" : [ "" ] ,
> "srv.type" : "Quads"
> } ,
> {
> "srv.description" : "Graph Store Protocol" ,
> "srv.endpoints" : [ "data" ] ,
> "srv.type" : "GSP"
> } ,
> {
> "srv.description" : "SPARQL Update" ,
> "srv.endpoints" : [ "update" ] ,
> "srv.type" : "Update"
> } ,
> {
> "srv.description" : "SPARQL Query" ,
> "srv.endpoints" : [
> "sparql" ,
> "query"
> ] ,
> "srv.type" : "Query"
> } ,
> {
> "srv.description" : "File Upload" ,
> "srv.endpoints" : [ "upload" ] ,
> "srv.type" : "Upload"
> }
> ] ,
> "ds.state" : true
> }
> [~/workspace/jena-fuseki2]
> ian@ian-desktop $ curl -XDELETE -v http://localhost:3030/$/datasets/foo
> * Hostname was NOT found in DNS cache
> * Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 3030 (#0)
> > DELETE /$/datasets/foo HTTP/1.1
> > User-Agent: curl/7.35.0
> > Host: localhost:3030
> > Accept: */*
> >
> < HTTP/1.1 400 Failed to find dataset for '/foo'
> < Fuseki-Request-ID: 224
> < Access-Control-Allow-Origin: *
> * Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
> < Server: Fuseki (2.0.0.M2-SNAPSHOT)
> < Content-Length: 0
> <
> * Connection #0 to host localhost left intact
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JENA-738) HTTP PUT to GSP endpoint should replace existing content?
[
https://issues.apache.org/jira/browse/JENA-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051391#comment-14051391
]
Ian Dickinson commented on JENA-738:
{quote}
In your example, it's {{PUT}} on {{/ds/data}} is a quads operation and it
clears the dataset . All named graphs will be removed.
If you want per graph control, it'll need to use {{?default}} or {{?graph=...}}
{quote}
Ah, good point. Thanks!
> HTTP PUT to GSP endpoint should replace existing content?
> -
>
> Key: JENA-738
> URL: https://issues.apache.org/jira/browse/JENA-738
> Project: Apache Jena
> Issue Type: Bug
> Components: Fuseki
>Reporter: Ian Dickinson
> Labels: fuseki2
>
> Partly a question, and partly a suggestion for improvement: should HTTP PUT
> to the /data endpoint replace existing content in the graph? I'd like to
> suggest that it does, for the following reasons:
> * we already have POST to /data to add new content
> * it seems more consistent with the HTTP spec
> * it would support the use-case of 'get the current graph contents, edit it,
> put it back'
> Here's a test case:
> {noformat}
> ian@ian-desktop $ curl http://localhost:3030/foo/data
> {
> }
> [~/workspace/jena-fuseki2]
> ian@ian-desktop $ curl -XPUT -v -d '
> .' -H 'Content-Type: text/turtle'
> http://localhost:3030/foo/data
> * Hostname was NOT found in DNS cache
> * Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 3030 (#0)
> > PUT /foo/data HTTP/1.1
> > User-Agent: curl/7.35.0
> > Host: localhost:3030
> > Accept: */*
> > Content-Type: text/turtle
> > Content-Length: 59
> >
> * upload completely sent off: 59 out of 59 bytes
> < HTTP/1.1 200 OK
> < Fuseki-Request-ID: 235
> < Access-Control-Allow-Origin: *
> * Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
> < Server: Fuseki (2.0.0.M2-SNAPSHOT)
> < Content-Type: application/json
> < Transfer-Encoding: chunked
> <
> {
> "count" : 1 ,
> "quadCount" : 0 ,
> "tripleCount" : 1
> }
> * Connection #0 to host localhost left intact
> [~/workspace/jena-fuseki2]
> ian@ian-desktop $ curl http://localhost:3030/foo/data
> {
> .
> }
> [~/workspace/jena-fuseki2]
> ian@ian-desktop $ curl -XPUT -v -d '
> .' -H 'Content-Type: text/turtle'
> http://localhost:3030/foo/data
> * Hostname was NOT found in DNS cache
> * Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 3030 (#0)
> > PUT /foo/data HTTP/1.1
> > User-Agent: curl/7.35.0
> > Host: localhost:3030
> > Accept: */*
> > Content-Type: text/turtle
> > Content-Length: 59
> >
> * upload completely sent off: 59 out of 59 bytes
> < HTTP/1.1 200 OK
> < Fuseki-Request-ID: 237
> < Access-Control-Allow-Origin: *
> * Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
> < Server: Fuseki (2.0.0.M2-SNAPSHOT)
> < Content-Type: application/json
> < Transfer-Encoding: chunked
> <
> {
> "count" : 1 ,
> "quadCount" : 0 ,
> "tripleCount" : 1
> }
> * Connection #0 to host localhost left intact
> [~/workspace/jena-fuseki2]
> ian@ian-desktop $ curl http://localhost:3030/foo/data
> {
> , .
> }
> {noformat}
> What I am suggesting is that the final GET returns a graph of one triple:
> :foo \:p :b
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (JENA-737) Deleting a dataset has stopped working
[
https://issues.apache.org/jira/browse/JENA-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Dickinson updated JENA-737:
---
Description:
Deleting a dataset using the HTTP DELETE verb isn't working (or I've got it
wrong). I think the following sequence used to work in Fuseki2, but now is
returning a 400 error:
{noformat}
$ curl http://localhost:3030/$/datasets/foo
{
"ds.name" : "/foo" ,
"ds.services" : [
{
"srv.description" : "Graph Store Protocol (Read)" ,
"srv.endpoints" : [ "get" ] ,
"srv.type" : "GSP_R"
} ,
{
"srv.description" : "HTTP Quads" ,
"srv.endpoints" : [ "" ] ,
"srv.type" : "Quads"
} ,
{
"srv.description" : "Graph Store Protocol" ,
"srv.endpoints" : [ "data" ] ,
"srv.type" : "GSP"
} ,
{
"srv.description" : "SPARQL Update" ,
"srv.endpoints" : [ "update" ] ,
"srv.type" : "Update"
} ,
{
"srv.description" : "SPARQL Query" ,
"srv.endpoints" : [
"sparql" ,
"query"
] ,
"srv.type" : "Query"
} ,
{
"srv.description" : "File Upload" ,
"srv.endpoints" : [ "upload" ] ,
"srv.type" : "Upload"
}
] ,
"ds.state" : true
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -XDELETE -v http://localhost:3030/$/datasets/foo
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3030 (#0)
> DELETE /$/datasets/foo HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:3030
> Accept: */*
>
< HTTP/1.1 400 Failed to find dataset for '/foo'
< Fuseki-Request-ID: 224
< Access-Control-Allow-Origin: *
* Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
< Server: Fuseki (2.0.0.M2-SNAPSHOT)
< Content-Length: 0
<
* Connection #0 to host localhost left intact
{noformat}
was:
Deleting a dataset using the HTTP DELETE verb isn't working (or I've got it
wrong). I think the following sequence used to work in Fuseki2, but now is
returning a 400 error:
{code}
$ curl http://localhost:3030/$/datasets/foo
{
"ds.name" : "/foo" ,
"ds.services" : [
{
"srv.description" : "Graph Store Protocol (Read)" ,
"srv.endpoints" : [ "get" ] ,
"srv.type" : "GSP_R"
} ,
{
"srv.description" : "HTTP Quads" ,
"srv.endpoints" : [ "" ] ,
"srv.type" : "Quads"
} ,
{
"srv.description" : "Graph Store Protocol" ,
"srv.endpoints" : [ "data" ] ,
"srv.type" : "GSP"
} ,
{
"srv.description" : "SPARQL Update" ,
"srv.endpoints" : [ "update" ] ,
"srv.type" : "Update"
} ,
{
"srv.description" : "SPARQL Query" ,
"srv.endpoints" : [
"sparql" ,
"query"
] ,
"srv.type" : "Query"
} ,
{
"srv.description" : "File Upload" ,
"srv.endpoints" : [ "upload" ] ,
"srv.type" : "Upload"
}
] ,
"ds.state" : true
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -XDELETE -v http://localhost:3030/$/datasets/foo
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3030 (#0)
> DELETE /$/datasets/foo HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:3030
> Accept: */*
>
< HTTP/1.1 400 Failed to find dataset for '/foo'
< Fuseki-Request-ID: 224
< Access-Control-Allow-Origin: *
* Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
< Server: Fuseki (2.0.0.M2-SNAPSHOT)
< Content-Length: 0
<
* Connection #0 to host localhost left intact
{code}
> Deleting a dataset has stopped working
> --
>
> Key: JENA-737
> URL: https://issues.apache.org/jira/browse/JENA-737
> Project: Apache Jena
> Issue Type: Bug
> Components: Fuseki
>Reporter: Ian Dickinson
>Priority: Minor
> Labels: fuseki2
>
> Deleting a dataset using the HTTP DELETE verb isn't working (or I've got it
> wrong). I think the following sequence used to work in Fuseki2, but now is
> returning a 400 error:
> {noformat}
> $ curl http://localhost:3030/$/datasets/foo
> {
> "ds.name" : "/foo" ,
> "ds.services" : [
> {
> "srv.description" : "Graph Store Protocol (Read)" ,
> "srv.endpoints" : [ "get" ] ,
> "srv.type" : "GSP_R"
> } ,
> {
> "srv.description" : "HTTP Quads" ,
> "srv.endpoints" : [ "" ] ,
> "srv.type" : "Quads"
> } ,
> {
> "srv.description" : "Graph Store Protocol" ,
> "srv.endpoints" : [ "data" ] ,
> "srv.type" : "GSP"
> } ,
> {
> "srv.description" : "SPARQL Update" ,
> "srv.endpoints" : [ "update" ] ,
> "srv.type" : "Update"
> } ,
> {
[jira] [Created] (JENA-738) HTTP PUT to GSP endpoint should replace existing content?
Ian Dickinson created JENA-738:
--
Summary: HTTP PUT to GSP endpoint should replace existing content?
Key: JENA-738
URL: https://issues.apache.org/jira/browse/JENA-738
Project: Apache Jena
Issue Type: Improvement
Components: Fuseki
Reporter: Ian Dickinson
Priority: Minor
Partly a question, and partly a suggestion for improvement: should HTTP PUT to
the /data endpoint replace existing content in the graph? I'd like to suggest
that it does, for the following reasons:
* we already have POST to /data to add new content
* it seems more consistent with the HTTP spec
* it would support the use-case of 'get the current graph contents, edit it,
put it back'
Here's a test case:
{noformat}
ian@ian-desktop $ curl http://localhost:3030/foo/data
{
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -XPUT -v -d '
.' -H 'Content-Type: text/turtle'
http://localhost:3030/foo/data
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3030 (#0)
> PUT /foo/data HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:3030
> Accept: */*
> Content-Type: text/turtle
> Content-Length: 59
>
* upload completely sent off: 59 out of 59 bytes
< HTTP/1.1 200 OK
< Fuseki-Request-ID: 235
< Access-Control-Allow-Origin: *
* Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
< Server: Fuseki (2.0.0.M2-SNAPSHOT)
< Content-Type: application/json
< Transfer-Encoding: chunked
<
{
"count" : 1 ,
"quadCount" : 0 ,
"tripleCount" : 1
}
* Connection #0 to host localhost left intact
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl http://localhost:3030/foo/data
{
.
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -XPUT -v -d '
.' -H 'Content-Type: text/turtle'
http://localhost:3030/foo/data
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3030 (#0)
> PUT /foo/data HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:3030
> Accept: */*
> Content-Type: text/turtle
> Content-Length: 59
>
* upload completely sent off: 59 out of 59 bytes
< HTTP/1.1 200 OK
< Fuseki-Request-ID: 237
< Access-Control-Allow-Origin: *
* Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
< Server: Fuseki (2.0.0.M2-SNAPSHOT)
< Content-Type: application/json
< Transfer-Encoding: chunked
<
{
"count" : 1 ,
"quadCount" : 0 ,
"tripleCount" : 1
}
* Connection #0 to host localhost left intact
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl http://localhost:3030/foo/data
{
, .
}
{noformat}
What I am suggesting is that the final GET returns a graph of one triple: :foo
\:p :b
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (JENA-737) Deleting a dataset has stopped working
Ian Dickinson created JENA-737:
--
Summary: Deleting a dataset has stopped working
Key: JENA-737
URL: https://issues.apache.org/jira/browse/JENA-737
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Reporter: Ian Dickinson
Priority: Minor
Deleting a dataset using the HTTP DELETE verb isn't working (or I've got it
wrong). I think the following sequence used to work in Fuseki2, but now is
returning a 400 error:
{code}
$ curl http://localhost:3030/$/datasets/foo
{
"ds.name" : "/foo" ,
"ds.services" : [
{
"srv.description" : "Graph Store Protocol (Read)" ,
"srv.endpoints" : [ "get" ] ,
"srv.type" : "GSP_R"
} ,
{
"srv.description" : "HTTP Quads" ,
"srv.endpoints" : [ "" ] ,
"srv.type" : "Quads"
} ,
{
"srv.description" : "Graph Store Protocol" ,
"srv.endpoints" : [ "data" ] ,
"srv.type" : "GSP"
} ,
{
"srv.description" : "SPARQL Update" ,
"srv.endpoints" : [ "update" ] ,
"srv.type" : "Update"
} ,
{
"srv.description" : "SPARQL Query" ,
"srv.endpoints" : [
"sparql" ,
"query"
] ,
"srv.type" : "Query"
} ,
{
"srv.description" : "File Upload" ,
"srv.endpoints" : [ "upload" ] ,
"srv.type" : "Upload"
}
] ,
"ds.state" : true
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -XDELETE -v http://localhost:3030/$/datasets/foo
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3030 (#0)
> DELETE /$/datasets/foo HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:3030
> Accept: */*
>
< HTTP/1.1 400 Failed to find dataset for '/foo'
< Fuseki-Request-ID: 224
< Access-Control-Allow-Origin: *
* Server Fuseki (2.0.0.M2-SNAPSHOT) is not blacklisted
< Server: Fuseki (2.0.0.M2-SNAPSHOT)
< Content-Length: 0
<
* Connection #0 to host localhost left intact
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JENA-731) schemagen does not add the generated source directory to the source roots
[ https://issues.apache.org/jira/browse/JENA-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045909#comment-14045909 ] Ian Dickinson commented on JENA-731: I think this is an improvement, not a bug. As I understood it the previous default, target/generated-sources, is already a source root by default. I'm concerned that changing the *default* output directory with no warning could break users' builds, if they have other tools that use the current output location. At the very least, this change should be documented in the changelog. > schemagen does not add the generated source directory to the source roots > - > > Key: JENA-731 > URL: https://issues.apache.org/jira/browse/JENA-731 > Project: Apache Jena > Issue Type: Bug > Components: Cmd line tools >Affects Versions: Jena 2.11.2 >Reporter: Benson Margulies > Fix For: Jena 2.12.0 > > > The plugin neglects to add a source root. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JENA-722) Fuseki2: report online/offline status for dataset
Ian Dickinson created JENA-722:
--
Summary: Fuseki2: report online/offline status for dataset
Key: JENA-722
URL: https://issues.apache.org/jira/browse/JENA-722
Project: Apache Jena
Issue Type: Improvement
Components: Fuseki
Reporter: Ian Dickinson
Priority: Minor
A dataset can be switched offline by posting to
{{/$/datasets/foo?state=offline}}. This is working. It would be nice to report
the online/offline status of the dataset when listing the datasets via a get on
{{/$/datasets}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (JENA-719) Fuseki2: report uptime as part of server status
Ian Dickinson created JENA-719: -- Summary: Fuseki2: report uptime as part of server status Key: JENA-719 URL: https://issues.apache.org/jira/browse/JENA-719 Project: Apache Jena Issue Type: Improvement Components: Fuseki Reporter: Ian Dickinson Priority: Minor It might be nice to return the server uptime as part of the /$/server status report. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JENA-718) Fuseki2 API: get /$/server not working
Ian Dickinson created JENA-718:
--
Summary: Fuseki2 API: get /$/server not working
Key: JENA-718
URL: https://issues.apache.org/jira/browse/JENA-718
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Reporter: Ian Dickinson
An HTTP GET to /$/server should return the current server status and endpoints,
but is currently returning 404.
{code}
ian@ian-desktop $ curl -H "Accept: application/json"
http://localhost:3030/$/server
Error 404: Not Found
Fuseki - version 2.0.0.M2-SNAPSHOT (Build date: ${maven.build.timestamp})
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (JENA-717) Fuseki2 delete dataset not working
Ian Dickinson created JENA-717:
--
Summary: Fuseki2 delete dataset not working
Key: JENA-717
URL: https://issues.apache.org/jira/browse/JENA-717
Project: Apache Jena
Issue Type: Bug
Components: Fuseki
Reporter: Ian Dickinson
Attempting to delete a dataset with an HTTP DELETE request gives a 400 error.
Probably pilot error, but I'm not sure what I'm doing wrong:
{code}
ian@ian-desktop $ curl -i 'http://localhost:3030/$/datasets/foo'
HTTP/1.1 200 OK
Fuseki-Request-ID: 10
Access-Control-Allow-Origin: *
Server: Fuseki (2.0.0.M2-SNAPSHOT)
Vary: Accept,Accept-Encoding,Accept-Charset
Content-Type: application/json
Transfer-Encoding: chunked
{
"ds.name" : "/foo" ,
"ds.services" : [
{
"srv.endpoints" : [ "get" ] ,
"srv.type" : "graph store protocol (Read)"
} ,
{
"srv.endpoints" : [ "update" ] ,
"srv.type" : "update"
} ,
{
"srv.endpoints" : [ "" ] ,
"srv.type" : "Quads"
} ,
{
"srv.endpoints" : [ "data" ] ,
"srv.type" : "graph store protocol"
} ,
{
"srv.endpoints" : [
"sparql" ,
"query"
] ,
"srv.type" : "query"
} ,
{
"srv.endpoints" : [ "upload" ] ,
"srv.type" : "upload"
}
]
}
[~/workspace/jena-fuseki2]
ian@ian-desktop $ curl -i -X DELETE http://localhost:3030/$/datasets/foo
HTTP/1.1 400 Failed to find dataset for '/foo'
Fuseki-Request-ID: 11
Access-Control-Allow-Origin: *
Server: Fuseki (2.0.0.M2-SNAPSHOT)
Content-Length:
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JENA-636) No configuration option for setting output encoding in schemagen
[ https://issues.apache.org/jira/browse/JENA-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13890792#comment-13890792 ] Ian Dickinson commented on JENA-636: I should have been clearer. Yes, it's schemagen not the plugin itself - there's currently no way to set an output encoding other than platform default. The action here is to add a configuration option to schemagen, and ensure that it has an effect on the output stream! > No configuration option for setting output encoding in schemagen > > > Key: JENA-636 > URL: https://issues.apache.org/jira/browse/JENA-636 > Project: Apache Jena > Issue Type: Bug > Components: Cmd line tools >Affects Versions: Jena 2.11.1 >Reporter: Ian Dickinson >Assignee: Ian Dickinson >Priority: Minor > > User reported a problem that Java source files generated by schemagen are > only created with character encoding cp1252, whereas his source files need to > be in UTF-8 to cope with international characters in the ontology content. > At present, there is no configuration option to set the character encoding on > the output file, so this would need to be added to schemagen. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (JENA-635) Add LSB init daemon support to fuseki startup script
[ https://issues.apache.org/jira/browse/JENA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13890789#comment-13890789 ] Ian Dickinson commented on JENA-635: OK, I have checked and - for me at least - it does run from the command line. If the lsb init functions are available from the usual place it will load them, otherwise it default to using echo. I also tweaked the script so that the start file can be specified in the environment or via /etc/default > Add LSB init daemon support to fuseki startup script > > > Key: JENA-635 > URL: https://issues.apache.org/jira/browse/JENA-635 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Reporter: Ian Dickinson >Assignee: Ian Dickinson >Priority: Minor > Attachments: fuseki-init.d.patch > > > I have made some improvements to the Fuseki startup script, so that it works > more easily as an init.d service script. Specifically, I have: > * allowed default values for variables to be loaded from /etc/default, so > that changing local setup does not require editing the script > * switched to using lsb_daemon_log rather than echo for output > * added fallbacks so that echo will be used if the lsb init functions are not > available > * switched to using 'ps -p' rather than 'kill -0' to find out if a process is > running > * made the location of the PID file more flexible. > This is a call for review of these changes, and in particular test reports > from other environments. I have tested on Ubuntu 12.04LTS, 13.10 and 14.04. I > have not tested on MaxOS, cygwin or other Linux distros, and would welcome > test reports and implementation improvements. > The full revised script is in a gist: > https://gist.github.com/ephemerian/8802368 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (JENA-635) Add LSB init daemon support to fuseki startup script
[ https://issues.apache.org/jira/browse/JENA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson updated JENA-635: --- Attachment: fuseki-init.d.patch Revised to ensure that it starts from the command line > Add LSB init daemon support to fuseki startup script > > > Key: JENA-635 > URL: https://issues.apache.org/jira/browse/JENA-635 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Reporter: Ian Dickinson >Assignee: Ian Dickinson >Priority: Minor > Attachments: fuseki-init.d.patch > > > I have made some improvements to the Fuseki startup script, so that it works > more easily as an init.d service script. Specifically, I have: > * allowed default values for variables to be loaded from /etc/default, so > that changing local setup does not require editing the script > * switched to using lsb_daemon_log rather than echo for output > * added fallbacks so that echo will be used if the lsb init functions are not > available > * switched to using 'ps -p' rather than 'kill -0' to find out if a process is > running > * made the location of the PID file more flexible. > This is a call for review of these changes, and in particular test reports > from other environments. I have tested on Ubuntu 12.04LTS, 13.10 and 14.04. I > have not tested on MaxOS, cygwin or other Linux distros, and would welcome > test reports and implementation improvements. > The full revised script is in a gist: > https://gist.github.com/ephemerian/8802368 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (JENA-635) Add LSB init daemon support to fuseki startup script
[ https://issues.apache.org/jira/browse/JENA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson updated JENA-635: --- Attachment: (was: fuseki-init.d.patch) > Add LSB init daemon support to fuseki startup script > > > Key: JENA-635 > URL: https://issues.apache.org/jira/browse/JENA-635 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Reporter: Ian Dickinson >Assignee: Ian Dickinson >Priority: Minor > Attachments: fuseki-init.d.patch > > > I have made some improvements to the Fuseki startup script, so that it works > more easily as an init.d service script. Specifically, I have: > * allowed default values for variables to be loaded from /etc/default, so > that changing local setup does not require editing the script > * switched to using lsb_daemon_log rather than echo for output > * added fallbacks so that echo will be used if the lsb init functions are not > available > * switched to using 'ps -p' rather than 'kill -0' to find out if a process is > running > * made the location of the PID file more flexible. > This is a call for review of these changes, and in particular test reports > from other environments. I have tested on Ubuntu 12.04LTS, 13.10 and 14.04. I > have not tested on MaxOS, cygwin or other Linux distros, and would welcome > test reports and implementation improvements. > The full revised script is in a gist: > https://gist.github.com/ephemerian/8802368 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (JENA-635) Add LSB init daemon support to fuseki startup script
[ https://issues.apache.org/jira/browse/JENA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13890716#comment-13890716 ] Ian Dickinson commented on JENA-635: Good thought, I'll investigate. > Add LSB init daemon support to fuseki startup script > > > Key: JENA-635 > URL: https://issues.apache.org/jira/browse/JENA-635 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Reporter: Ian Dickinson >Assignee: Ian Dickinson >Priority: Minor > Attachments: fuseki-init.d.patch > > > I have made some improvements to the Fuseki startup script, so that it works > more easily as an init.d service script. Specifically, I have: > * allowed default values for variables to be loaded from /etc/default, so > that changing local setup does not require editing the script > * switched to using lsb_daemon_log rather than echo for output > * added fallbacks so that echo will be used if the lsb init functions are not > available > * switched to using 'ps -p' rather than 'kill -0' to find out if a process is > running > * made the location of the PID file more flexible. > This is a call for review of these changes, and in particular test reports > from other environments. I have tested on Ubuntu 12.04LTS, 13.10 and 14.04. I > have not tested on MaxOS, cygwin or other Linux distros, and would welcome > test reports and implementation improvements. > The full revised script is in a gist: > https://gist.github.com/ephemerian/8802368 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (JENA-636) No configuration option for setting output encoding in schemagen
Ian Dickinson created JENA-636: -- Summary: No configuration option for setting output encoding in schemagen Key: JENA-636 URL: https://issues.apache.org/jira/browse/JENA-636 Project: Apache Jena Issue Type: Bug Components: Cmd line tools Affects Versions: Jena 2.11.1 Reporter: Ian Dickinson Assignee: Ian Dickinson Priority: Minor User reported a problem that Java source files generated by schemagen are only created with character encoding cp1252, whereas his source files need to be in UTF-8 to cope with international characters in the ontology content. At present, there is no configuration option to set the character encoding on the output file, so this would need to be added to schemagen. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (JENA-635) Add LSB init daemon support to fuseki startup script
[ https://issues.apache.org/jira/browse/JENA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson updated JENA-635: --- Attachment: fuseki-init.d.patch Patch file for changes to fuseki init script > Add LSB init daemon support to fuseki startup script > > > Key: JENA-635 > URL: https://issues.apache.org/jira/browse/JENA-635 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Reporter: Ian Dickinson >Assignee: Ian Dickinson >Priority: Minor > Attachments: fuseki-init.d.patch > > > I have made some improvements to the Fuseki startup script, so that it works > more easily as an init.d service script. Specifically, I have: > * allowed default values for variables to be loaded from /etc/default, so > that changing local setup does not require editing the script > * switched to using lsb_daemon_log rather than echo for output > * added fallbacks so that echo will be used if the lsb init functions are not > available > * switched to using 'ps -p' rather than 'kill -0' to find out if a process is > running > * made the location of the PID file more flexible. > This is a call for review of these changes, and in particular test reports > from other environments. I have tested on Ubuntu 12.04LTS, 13.10 and 14.04. I > have not tested on MaxOS, cygwin or other Linux distros, and would welcome > test reports and implementation improvements. > The full revised script is in a gist: > https://gist.github.com/ephemerian/8802368 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (JENA-635) Add LSB init daemon support to fuseki startup script
[ https://issues.apache.org/jira/browse/JENA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson updated JENA-635: --- Assignee: Ian Dickinson > Add LSB init daemon support to fuseki startup script > > > Key: JENA-635 > URL: https://issues.apache.org/jira/browse/JENA-635 > Project: Apache Jena > Issue Type: Improvement > Components: Fuseki >Reporter: Ian Dickinson >Assignee: Ian Dickinson >Priority: Minor > > I have made some improvements to the Fuseki startup script, so that it works > more easily as an init.d service script. Specifically, I have: > * allowed default values for variables to be loaded from /etc/default, so > that changing local setup does not require editing the script > * switched to using lsb_daemon_log rather than echo for output > * added fallbacks so that echo will be used if the lsb init functions are not > available > * switched to using 'ps -p' rather than 'kill -0' to find out if a process is > running > * made the location of the PID file more flexible. > This is a call for review of these changes, and in particular test reports > from other environments. I have tested on Ubuntu 12.04LTS, 13.10 and 14.04. I > have not tested on MaxOS, cygwin or other Linux distros, and would welcome > test reports and implementation improvements. > The full revised script is in a gist: > https://gist.github.com/ephemerian/8802368 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (JENA-635) Add LSB init daemon support to fuseki startup script
Ian Dickinson created JENA-635: -- Summary: Add LSB init daemon support to fuseki startup script Key: JENA-635 URL: https://issues.apache.org/jira/browse/JENA-635 Project: Apache Jena Issue Type: Improvement Components: Fuseki Reporter: Ian Dickinson Priority: Minor I have made some improvements to the Fuseki startup script, so that it works more easily as an init.d service script. Specifically, I have: * allowed default values for variables to be loaded from /etc/default, so that changing local setup does not require editing the script * switched to using lsb_daemon_log rather than echo for output * added fallbacks so that echo will be used if the lsb init functions are not available * switched to using 'ps -p' rather than 'kill -0' to find out if a process is running * made the location of the PID file more flexible. This is a call for review of these changes, and in particular test reports from other environments. I have tested on Ubuntu 12.04LTS, 13.10 and 14.04. I have not tested on MaxOS, cygwin or other Linux distros, and would welcome test reports and implementation improvements. The full revised script is in a gist: https://gist.github.com/ephemerian/8802368 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (JENA-612) Fuseki does not log an error when failing to open a TDB dataset
Ian Dickinson created JENA-612: -- Summary: Fuseki does not log an error when failing to open a TDB dataset Key: JENA-612 URL: https://issues.apache.org/jira/browse/JENA-612 Project: Apache Jena Issue Type: Improvement Components: Fuseki Affects Versions: Fuseki 1.0.0 Reporter: Ian Dickinson Priority: Minor Steps to recreate: 1. Create a TDB dataset owned by user A, with no write permission for other or group. 2. Start fuseki via start-stop-daemon, per the fuseki init.d script provided in the distribution, with $FUSEKI_USER set to be a user other than A and --loc pointing to the dataset from step 1. 3. Fuseki starts, but then silently dies with no diagnostic. Analysis The --background flag in the start-stop-daemon call causes all stdout and stderr output to get silently swallowed. Fuseki does not log the failure to open the dataset to the log file, so the effect is that the daemon process terminates with no obvious explanation or diagnostic. What I would like to happen: Catch the FileException and make an entry in the Fuseki log. Stack trace for reference: com.hp.hpl.jena.tdb.base.file.FileException: Failed to open: /var/data-stores/transport/tdb/node2id.idn (mode=rw) at com.hp.hpl.jena.tdb.base.file.ChannelManager.open$(ChannelManager.java:82) at com.hp.hpl.jena.tdb.base.file.ChannelManager.openref$(ChannelManager.java:56) at com.hp.hpl.jena.tdb.base.file.ChannelManager.acquire(ChannelManager.java:45) at com.hp.hpl.jena.tdb.base.file.FileBase.(FileBase.java:61) at com.hp.hpl.jena.tdb.base.file.FileBase.(FileBase.java:50) at com.hp.hpl.jena.tdb.base.file.FileBase.create(FileBase.java:45) at com.hp.hpl.jena.tdb.base.file.BlockAccessBase.(BlockAccessBase.java:46) at com.hp.hpl.jena.tdb.base.file.BlockAccessMapped.(BlockAccessMapped.java:63) at com.hp.hpl.jena.tdb.base.block.BlockMgrFactory.createMMapFile(BlockMgrFactory.java:90) at com.hp.hpl.jena.tdb.base.block.BlockMgrFactory.createFile(BlockMgrFactory.java:80) at com.hp.hpl.jena.tdb.base.block.BlockMgrFactory.create(BlockMgrFactory.java:58) at com.hp.hpl.jena.tdb.setup.Builder$BlockMgrBuilderStd.buildBlockMgr(Builder.java:196) at com.hp.hpl.jena.tdb.setup.Builder$RangeIndexBuilderStd.createBPTree(Builder.java:165) at com.hp.hpl.jena.tdb.setup.Builder$RangeIndexBuilderStd.buildRangeIndex(Builder.java:134) at com.hp.hpl.jena.tdb.setup.Builder$IndexBuilderStd.buildIndex(Builder.java:112) at com.hp.hpl.jena.tdb.setup.Builder$NodeTableBuilderStd.buildNodeTable(Builder.java:85) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd$NodeTableBuilderRecorder.buildNodeTable(DatasetBuilderStd.java:382) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd.makeNodeTable(DatasetBuilderStd.java:293) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd._build(DatasetBuilderStd.java:159) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd.build(DatasetBuilderStd.java:149) at com.hp.hpl.jena.tdb.setup.DatasetBuilderStd.build(DatasetBuilderStd.java:64) at com.hp.hpl.jena.tdb.StoreConnection.make(StoreConnection.java:217) at com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction.(DatasetGraphTransaction.java:75) at com.hp.hpl.jena.tdb.sys.TDBMaker._create(TDBMaker.java:57) at com.hp.hpl.jena.tdb.sys.TDBMaker.createDatasetGraphTransaction(TDBMaker.java:45) at com.hp.hpl.jena.tdb.TDBFactory._createDatasetGraph(TDBFactory.java:104) at com.hp.hpl.jena.tdb.TDBFactory.createDatasetGraph(TDBFactory.java:73) at com.hp.hpl.jena.tdb.TDBFactory.createDatasetGraph(TDBFactory.java:69) at org.apache.jena.fuseki.FusekiCmd.processModulesAndArgs(FusekiCmd.java:266) at arq.cmdline.CmdArgModule.process(CmdArgModule.java:51) at arq.cmdline.CmdMain.mainMethod(CmdMain.java:100) at arq.cmdline.CmdMain.mainRun(CmdMain.java:63) at arq.cmdline.CmdMain.mainRun(CmdMain.java:50) at org.apache.jena.fuseki.FusekiCmd.main(FusekiCmd.java:141) Caused by: java.io.FileNotFoundException: /var/data-stores/transport/tdb/node2id.idn (Permission denied) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.(RandomAccessFile.java:233) at java.io.RandomAccessFile.(RandomAccessFile.java:118) at com.hp.hpl.jena.tdb.base.file.ChannelManager.open$(ChannelManager.java:79) ... 33 more -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Closed] (JENA-596) Schemagen does not work with Maven 3.1.x
[ https://issues.apache.org/jira/browse/JENA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson closed JENA-596. -- > Schemagen does not work with Maven 3.1.x > > > Key: JENA-596 > URL: https://issues.apache.org/jira/browse/JENA-596 > Project: Apache Jena > Issue Type: Bug >Reporter: Ian Dickinson >Assignee: Ian Dickinson > Fix For: Jena 2.11.1 > > Attachments: jena-maven-tools.patch > > > Maven 3.1.x has changed the way that POM parameters are passed to plugin > code, causing the schemagen Maven plugin to break. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (JENA-596) Schemagen does not work with Maven 3.1.x
[ https://issues.apache.org/jira/browse/JENA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson resolved JENA-596. Resolution: Fixed Fix Version/s: Jena 2.11.1 > Schemagen does not work with Maven 3.1.x > > > Key: JENA-596 > URL: https://issues.apache.org/jira/browse/JENA-596 > Project: Apache Jena > Issue Type: Bug >Reporter: Ian Dickinson >Assignee: Ian Dickinson > Fix For: Jena 2.11.1 > > Attachments: jena-maven-tools.patch > > > Maven 3.1.x has changed the way that POM parameters are passed to plugin > code, causing the schemagen Maven plugin to break. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-596) Schemagen does not work with Maven 3.1.x
[ https://issues.apache.org/jira/browse/JENA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832519#comment-13832519 ] Ian Dickinson commented on JENA-596: I think the clone projects warning is spurious. I had a quick look at the source, and it appears to be a generic warning that just comes up automatically if you don't specify a cloneProjectsTo directory. I think we can safely ignore it. > Schemagen does not work with Maven 3.1.x > > > Key: JENA-596 > URL: https://issues.apache.org/jira/browse/JENA-596 > Project: Apache Jena > Issue Type: Bug >Reporter: Ian Dickinson >Assignee: Ian Dickinson > Attachments: jena-maven-tools.patch > > > Maven 3.1.x has changed the way that POM parameters are passed to plugin > code, causing the schemagen Maven plugin to break. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-596) Schemagen does not work with Maven 3.1.x
[ https://issues.apache.org/jira/browse/JENA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831874#comment-13831874 ] Ian Dickinson commented on JENA-596: Patch applied and committed, thank you Shane. AndyS - can you please confirm that it works for you now before I close the issue? > Schemagen does not work with Maven 3.1.x > > > Key: JENA-596 > URL: https://issues.apache.org/jira/browse/JENA-596 > Project: Apache Jena > Issue Type: Bug >Reporter: Ian Dickinson >Assignee: Ian Dickinson > Attachments: jena-maven-tools.patch > > > Maven 3.1.x has changed the way that POM parameters are passed to plugin > code, causing the schemagen Maven plugin to break. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (JENA-596) Schemagen does not work with Maven 3.1.x
Ian Dickinson created JENA-596: -- Summary: Schemagen does not work with Maven 3.1.x Key: JENA-596 URL: https://issues.apache.org/jira/browse/JENA-596 Project: Apache Jena Issue Type: Bug Reporter: Ian Dickinson Assignee: Ian Dickinson Maven 3.1.x has changed the way that POM parameters are passed to plugin code, causing the schemagen Maven plugin to break. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (JENA-420) Web-based User Interface for Jena Fuseki
[ https://issues.apache.org/jira/browse/JENA-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814934#comment-13814934 ] Ian Dickinson edited comment on JENA-420 at 11/6/13 2:48 PM: - Andy - what are the gspRead and gspReadWrite services, and why does gspRead not have an endpoint? was (Author: ijd): Andy - what are the gspRead and gspReadWrite services, and why does gspRead not have an endpoint? > Web-based User Interface for Jena Fuseki > > > Key: JENA-420 > URL: https://issues.apache.org/jira/browse/JENA-420 > Project: Apache Jena > Issue Type: New Feature > Components: Fuseki >Reporter: Stephen Allen > Labels: gsoc2013, java, javascript, mentor, rdf, sparql, > velocity, web > Attachments: fuseki1.png, fuseki2.png, fuseki3.png, fuseki4.png > > > Fuseki could use an overhaul / rewrite of the web interface. It would be > great to design a nice web-based GUI interface for both querying/exploring > the data and for managing Fuseki itself. > Tools and skills that may be required: > Java, HTML+CSS, Javascript, Velocity (templates used server-side in place of > JSP) > A few ideas to get started: > 1) Resource Explorer > This interface allows the user to select any resource from either a list of > all triples in a graph, or from the results of a SPARQL query. After > selecting the resource, they can view all of the statements that reference > the resource. > 2) Improved Query Input > It would be great to enhance the query input form for both queries and > updates. Some features here that could be useful would be an IDE-like input > box that performed syntax highlighting, automatic indentation, and easy > commenting out of selected lines of text. Additionally being able to > pre-populate the input box with the user's commonly used prefixes would be > great (stored in a cookie or some such). > 3) Improved Query Results > Better display of query results (especially SELECT queries). Already > mentioned was a tie-in to the Resource Explorer, so a user can easily see the > statements about some interesting resource in the results. But it would also > be great to layout and format the result table better. Even display the > results on the same page as the query input box using AJAX. Or allow the > table to be resorted after the query results have been returned. Also > display the total number of rows. > 4) Query Management > View and manage currently running queries. Display how long queries have > been executing, and allow the user to cancel queries that may be taking too > long. > 5) Fuseki Management > There are many tasks here that would be great. Expose JVM properties via JMX > in a nice UI. Things like CPU/Memory usage, disk space remaining, etc. > Allow initiation of back-up tasks. Allow the user to download a snapshot of > the repository. Shut down the server. Possibly add and remove datasets > dynamically. > Attached are screenshots indicating the current UI and the workflow for > issuing a query. The idea would be to overhaul and replace most of this! -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (JENA-420) Web-based User Interface for Jena Fuseki
[ https://issues.apache.org/jira/browse/JENA-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814934#comment-13814934 ] Ian Dickinson edited comment on JENA-420 at 11/6/13 2:48 PM: - Andy - what are the gspRead and gspReadWrite services, and why does gspRead not have an endpoint? was (Author: ijd): Andy - what are the `gspRead` and `gspReadWrite` services, and why does `gspRead` not have an endpoint? > Web-based User Interface for Jena Fuseki > > > Key: JENA-420 > URL: https://issues.apache.org/jira/browse/JENA-420 > Project: Apache Jena > Issue Type: New Feature > Components: Fuseki >Reporter: Stephen Allen > Labels: gsoc2013, java, javascript, mentor, rdf, sparql, > velocity, web > Attachments: fuseki1.png, fuseki2.png, fuseki3.png, fuseki4.png > > > Fuseki could use an overhaul / rewrite of the web interface. It would be > great to design a nice web-based GUI interface for both querying/exploring > the data and for managing Fuseki itself. > Tools and skills that may be required: > Java, HTML+CSS, Javascript, Velocity (templates used server-side in place of > JSP) > A few ideas to get started: > 1) Resource Explorer > This interface allows the user to select any resource from either a list of > all triples in a graph, or from the results of a SPARQL query. After > selecting the resource, they can view all of the statements that reference > the resource. > 2) Improved Query Input > It would be great to enhance the query input form for both queries and > updates. Some features here that could be useful would be an IDE-like input > box that performed syntax highlighting, automatic indentation, and easy > commenting out of selected lines of text. Additionally being able to > pre-populate the input box with the user's commonly used prefixes would be > great (stored in a cookie or some such). > 3) Improved Query Results > Better display of query results (especially SELECT queries). Already > mentioned was a tie-in to the Resource Explorer, so a user can easily see the > statements about some interesting resource in the results. But it would also > be great to layout and format the result table better. Even display the > results on the same page as the query input box using AJAX. Or allow the > table to be resorted after the query results have been returned. Also > display the total number of rows. > 4) Query Management > View and manage currently running queries. Display how long queries have > been executing, and allow the user to cancel queries that may be taking too > long. > 5) Fuseki Management > There are many tasks here that would be great. Expose JVM properties via JMX > in a nice UI. Things like CPU/Memory usage, disk space remaining, etc. > Allow initiation of back-up tasks. Allow the user to download a snapshot of > the repository. Shut down the server. Possibly add and remove datasets > dynamically. > Attached are screenshots indicating the current UI and the workflow for > issuing a query. The idea would be to overhaul and replace most of this! -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-420) Web-based User Interface for Jena Fuseki
[ https://issues.apache.org/jira/browse/JENA-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814934#comment-13814934 ] Ian Dickinson commented on JENA-420: Andy - what are the `gspRead` and `gspReadWrite` services, and why does `gspRead` not have an endpoint? > Web-based User Interface for Jena Fuseki > > > Key: JENA-420 > URL: https://issues.apache.org/jira/browse/JENA-420 > Project: Apache Jena > Issue Type: New Feature > Components: Fuseki >Reporter: Stephen Allen > Labels: gsoc2013, java, javascript, mentor, rdf, sparql, > velocity, web > Attachments: fuseki1.png, fuseki2.png, fuseki3.png, fuseki4.png > > > Fuseki could use an overhaul / rewrite of the web interface. It would be > great to design a nice web-based GUI interface for both querying/exploring > the data and for managing Fuseki itself. > Tools and skills that may be required: > Java, HTML+CSS, Javascript, Velocity (templates used server-side in place of > JSP) > A few ideas to get started: > 1) Resource Explorer > This interface allows the user to select any resource from either a list of > all triples in a graph, or from the results of a SPARQL query. After > selecting the resource, they can view all of the statements that reference > the resource. > 2) Improved Query Input > It would be great to enhance the query input form for both queries and > updates. Some features here that could be useful would be an IDE-like input > box that performed syntax highlighting, automatic indentation, and easy > commenting out of selected lines of text. Additionally being able to > pre-populate the input box with the user's commonly used prefixes would be > great (stored in a cookie or some such). > 3) Improved Query Results > Better display of query results (especially SELECT queries). Already > mentioned was a tie-in to the Resource Explorer, so a user can easily see the > statements about some interesting resource in the results. But it would also > be great to layout and format the result table better. Even display the > results on the same page as the query input box using AJAX. Or allow the > table to be resorted after the query results have been returned. Also > display the total number of rows. > 4) Query Management > View and manage currently running queries. Display how long queries have > been executing, and allow the user to cancel queries that may be taking too > long. > 5) Fuseki Management > There are many tasks here that would be great. Expose JVM properties via JMX > in a nice UI. Things like CPU/Memory usage, disk space remaining, etc. > Allow initiation of back-up tasks. Allow the user to download a snapshot of > the repository. Shut down the server. Possibly add and remove datasets > dynamically. > Attached are screenshots indicating the current UI and the workflow for > issuing a query. The idea would be to overhaul and replace most of this! -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-420) Web-based User Interface for Jena Fuseki
[ https://issues.apache.org/jira/browse/JENA-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810080#comment-13810080 ] Ian Dickinson commented on JENA-420: Branch where we're working on the new UI implementation: http://svn.apache.org/repos/asf/jena/branches/jena-fuseki-new-ui/ > Web-based User Interface for Jena Fuseki > > > Key: JENA-420 > URL: https://issues.apache.org/jira/browse/JENA-420 > Project: Apache Jena > Issue Type: New Feature > Components: Fuseki >Reporter: Stephen Allen > Labels: gsoc2013, java, javascript, mentor, rdf, sparql, > velocity, web > Attachments: fuseki1.png, fuseki2.png, fuseki3.png, fuseki4.png > > > Fuseki could use an overhaul / rewrite of the web interface. It would be > great to design a nice web-based GUI interface for both querying/exploring > the data and for managing Fuseki itself. > Tools and skills that may be required: > Java, HTML+CSS, Javascript, Velocity (templates used server-side in place of > JSP) > A few ideas to get started: > 1) Resource Explorer > This interface allows the user to select any resource from either a list of > all triples in a graph, or from the results of a SPARQL query. After > selecting the resource, they can view all of the statements that reference > the resource. > 2) Improved Query Input > It would be great to enhance the query input form for both queries and > updates. Some features here that could be useful would be an IDE-like input > box that performed syntax highlighting, automatic indentation, and easy > commenting out of selected lines of text. Additionally being able to > pre-populate the input box with the user's commonly used prefixes would be > great (stored in a cookie or some such). > 3) Improved Query Results > Better display of query results (especially SELECT queries). Already > mentioned was a tie-in to the Resource Explorer, so a user can easily see the > statements about some interesting resource in the results. But it would also > be great to layout and format the result table better. Even display the > results on the same page as the query input box using AJAX. Or allow the > table to be resorted after the query results have been returned. Also > display the total number of rows. > 4) Query Management > View and manage currently running queries. Display how long queries have > been executing, and allow the user to cancel queries that may be taking too > long. > 5) Fuseki Management > There are many tasks here that would be great. Expose JVM properties via JMX > in a nice UI. Things like CPU/Memory usage, disk space remaining, etc. > Allow initiation of back-up tasks. Allow the user to download a snapshot of > the repository. Shut down the server. Possibly add and remove datasets > dynamically. > Attached are screenshots indicating the current UI and the workflow for > issuing a query. The idea would be to overhaul and replace most of this! -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (JENA-482) Website re-organisation and facelift
[ https://issues.apache.org/jira/browse/JENA-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13748446#comment-13748446 ] Ian Dickinson commented on JENA-482: Hi Samuel, I like the breadcrumbs. I think keeping it on top is the right thing. It occurred to me that there's another use case that this supports, which is users arriving at the page via a search engine. They now have a much clearer idea where they are in terms of the project's information collection. I'd support Leigh's suggestion of having the version number easily visible on the web site. The use case this supports is: "I'm using Jena, or thinking of doing so, and I'd like to quickly check what the latest version is". Currently, you have to go to the download link, navigate to the right folder, see which is the latest archive file and parse the version number out of the file name. Which breaks the "don't make me think" rule, and then some! We can easily make updating the published version number part of the release process. For similar reasons, I'd also support putting the prominent download link back in. For people who have already "got started", and just need the latest version or to do a new install on another machine, the call-to-action we want is to download the software. Those comments aside, good job! I'm happy to see this go live when we roll the next Jena release. Ian > Website re-organisation and facelift > > > Key: JENA-482 > URL: https://issues.apache.org/jira/browse/JENA-482 > Project: Apache Jena > Issue Type: Documentation > Components: Web site >Reporter: Samuel Croset >Assignee: Rob Vesse >Priority: Minor > Labels: documentation > Attachments: new_website.diff > > > I've been experimenting a bit in the last couple of days over the Jena > website and documentation. You can see a live demo version of the result > here: http://loopasam.github.io/jena-doc/index.html > My motivation was to try to make the overall browsing experience a bit > clearer and nicer looking without disrupting too much what's already in place. > I have refactored some of the skeleton and CSS using Twitter Bootstrap. I > haven't changed any of the build mechanism (ASF-CMS), so pretty much all the > documents and pages are working just as before out of the box. > Before doing more work on this I wanted to know what the community thinks of > it and whether it could be integrated with the current code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-482) Website re-organisation and facelift
[ https://issues.apache.org/jira/browse/JENA-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744283#comment-13744283 ] Ian Dickinson commented on JENA-482: It's a great job, Samuel, thank you. I do think there's still a concern on second level navigation. Consider the following pages from the old and new design: http://jena.apache.org/documentation/tdb/assembler.html http://jena.staging.apache.org/documentation/tdb/assembler.html On the old site, while I'm looking at a page on TDB assembler I can still see (i) the range of other topics that I might want to dig into, in the case that TDB isn't (the only) Jena documentation I'm interested in, and (ii) some - though admittedly not all - of the other TDB topic pages. In the new design, I lose that second level context. To see the other TDB pages I have to click back, to see the other top-level documentation topics I have to go back twice. I'd be the first to admit that the old left-menu isn't perfect, and does look dated. It's imperfect because it's neither brief, nor complete. Andy and I debated this a bit back when Jena first migrated to Apache, and the current selection of topics in the nav menu is an uneasy compromise between compactness and completeness. But I think that some level of persistent second-level navigation does meet a need in the UX. There are a couple of ways we could address this. One would be to add some level of secondary navigation menu, as a second horizontal bar or a floating page menu. Another would be to add a trail with links to the next topic, previous topic and overview. Those serve different purposes, but I think either would add some useful orientation. There may be other solutions as well. > Website re-organisation and facelift > > > Key: JENA-482 > URL: https://issues.apache.org/jira/browse/JENA-482 > Project: Apache Jena > Issue Type: Documentation > Components: Web site >Reporter: Samuel Croset >Assignee: Rob Vesse >Priority: Minor > Labels: documentation > Attachments: new_website.diff > > > I've been experimenting a bit in the last couple of days over the Jena > website and documentation. You can see a live demo version of the result > here: http://loopasam.github.io/jena-doc/index.html > My motivation was to try to make the overall browsing experience a bit > clearer and nicer looking without disrupting too much what's already in place. > I have refactored some of the skeleton and CSS using Twitter Bootstrap. I > haven't changed any of the build mechanism (ASF-CMS), so pretty much all the > documents and pages are working just as before out of the box. > Before doing more work on this I wanted to know what the community thinks of > it and whether it could be integrated with the current code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-482) Website re-organisation and facelift
[ https://issues.apache.org/jira/browse/JENA-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13700560#comment-13700560 ] Ian Dickinson commented on JENA-482: Yes, I agree with adding a sidebar navigation once you get into the learn section. The problem is that most of the content on the site is in the page hierarchies under 'learn', so it's helpful to users to have a persistent visual reminder of where they are, and which other content categories are available to them. Without it, and just having the dropdown menu for top-level categories, it's rather disorientating. > Website re-organisation and facelift > > > Key: JENA-482 > URL: https://issues.apache.org/jira/browse/JENA-482 > Project: Apache Jena > Issue Type: Documentation > Components: Web site >Reporter: Samuel Croset >Priority: Minor > Labels: documentation > > I've been experimenting a bit in the last couple of days over the Jena > website and documentation. You can see a live demo version of the result > here: http://loopasam.github.io/jena-doc/index.html > My motivation was to try to make the overall browsing experience a bit > clearer and nicer looking without disrupting too much what's already in place. > I have refactored some of the skeleton and CSS using Twitter Bootstrap. I > haven't changed any of the build mechanism (ASF-CMS), so pretty much all the > documents and pages are working just as before out of the box. > Before doing more work on this I wanted to know what the community thinks of > it and whether it could be integrated with the current code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-450) Creating an OntModel can update the prefixes, causing a DB write.
[ https://issues.apache.org/jira/browse/JENA-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13655386#comment-13655386 ] Ian Dickinson commented on JENA-450: That was the conclusion I was coming to as well. As you say, this is a temporary work-around while we sort out how to do prefixes in a more robust way. Mocking a read-only graph might be a useful smoke test for other OntModel behaviours though, so it's probably something that It Would Be Nice To Do one day. > Creating an OntModel can update the prefixes, causing a DB write. > - > > Key: JENA-450 > URL: https://issues.apache.org/jira/browse/JENA-450 > Project: Apache Jena > Issue Type: Bug > Components: TDB >Affects Versions: TDB 0.10.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne > Fix For: Jena 2.10.1 > > Attachments: Jena450_OntModelPrefixesWrite.java > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-450) Creating an OntModel can update the prefixes, causing a DB write.
[ https://issues.apache.org/jira/browse/JENA-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13655330#comment-13655330 ] Ian Dickinson commented on JENA-450: Ah, OK, I'll drop my version. I was trying to work out how to write a test case and mock a read-only graph, without actually creating a TDB instance in a transaction. No worries. > Creating an OntModel can update the prefixes, causing a DB write. > - > > Key: JENA-450 > URL: https://issues.apache.org/jira/browse/JENA-450 > Project: Apache Jena > Issue Type: Bug > Components: TDB >Affects Versions: TDB 0.10.0 >Reporter: Andy Seaborne >Assignee: Andy Seaborne > Fix For: Jena 2.10.1 > > Attachments: Jena450_OntModelPrefixesWrite.java > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-357) rdfcat warnings appear on stdout
[ https://issues.apache.org/jira/browse/JENA-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504968#comment-13504968 ] Ian Dickinson commented on JENA-357: See http://jena.markmail.org/thread/ibhxqbsknpbaddam > rdfcat warnings appear on stdout > > > Key: JENA-357 > URL: https://issues.apache.org/jira/browse/JENA-357 > Project: Apache Jena > Issue Type: Bug > Components: Cmd line tools >Affects Versions: Jena 2.7.4 >Reporter: Ian Dickinson >Assignee: Ian Dickinson > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JENA-357) rdfcat warnings appear on stdout
Ian Dickinson created JENA-357: -- Summary: rdfcat warnings appear on stdout Key: JENA-357 URL: https://issues.apache.org/jira/browse/JENA-357 Project: Apache Jena Issue Type: Bug Components: Cmd line tools Affects Versions: Jena 2.7.4 Reporter: Ian Dickinson Assignee: Ian Dickinson -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JENA-353) RDFList.append doc indicates a copy is created not always so.
[ https://issues.apache.org/jira/browse/JENA-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson updated JENA-353: --- Assignee: Ian Dickinson > RDFList.append doc indicates a copy is created not always so. > - > > Key: JENA-353 > URL: https://issues.apache.org/jira/browse/JENA-353 > Project: Apache Jena > Issue Type: Bug >Affects Versions: Jena 2.7.4 >Reporter: Claude Warren >Assignee: Ian Dickinson > > Documentation for RDFList.append() indicates that a copy is created, both > lists are merged into the copy and the copy returned so as to be "non > side-effecting operation on either this list or the given list" > However, in the case where this list is empty the other list is returned. I > believe copy of the other should be returned in this case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-353) RDFList.append doc indicates a copy is created not always so.
[ https://issues.apache.org/jira/browse/JENA-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503443#comment-13503443 ] Ian Dickinson commented on JENA-353: What's the use case when this makes a difference? The documentation is correct: when you do L1.append( L2 ) where L1 == nil, the post-condition remains true that neither list has a different set of triples than it did before the append operation. If your application needs to copy the list so that the appended list (or the original) can be side-effected by other code, you have `RDFList.copy`. I'm happy to consider changes to the current contract, but the motivation needs to be clearer. Copying a list is potentially an expensive operation, so it should be very clear to the caller when it is going to take place. > RDFList.append doc indicates a copy is created not always so. > - > > Key: JENA-353 > URL: https://issues.apache.org/jira/browse/JENA-353 > Project: Apache Jena > Issue Type: Bug >Affects Versions: Jena 2.7.4 >Reporter: Claude Warren > > Documentation for RDFList.append() indicates that a copy is created, both > lists are merged into the copy and the copy returned so as to be "non > side-effecting operation on either this list or the given list" > However, in the case where this list is empty the other list is returned. I > believe copy of the other should be returned in this case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-333) Using javadoc 7 causes warning exception in build (DAMLVocabulary, DAML_OIL)
[
https://issues.apache.org/jira/browse/JENA-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13471945#comment-13471945
]
Ian Dickinson commented on JENA-333:
OK, I deleted the various DAML vocabulary classes in my local copy of Jena, and
then performed a bunch of edits to make the codebase consistent and the tests
pass. None of the edits were particularly bothersome - commenting out
DAML-specific tests and unparser behaviours - but there were quite a lot of
them. I think the right think to do is mark the classes as deprecated this
cycle, and I'll remove them - and make the codebase consistent - immediately
after we release so that they're gone in the next cycle. Would that be OK?
> Using javadoc 7 causes warning exception in build (DAMLVocabulary, DAML_OIL)
>
>
> Key: JENA-333
> URL: https://issues.apache.org/jira/browse/JENA-333
> Project: Apache Jena
> Issue Type: Bug
> Components: Build, Onotology API
>Affects Versions: Jena 2.7.4
> Environment: Java 7 (1.7.0_07) Linux 64 bit. (but not Java 1.6.0_24)
>Reporter: Andy Seaborne
>Assignee: Ian Dickinson
>Priority: Minor
>
> Under java7, the build of jena core gets two stacktraces (marked as warning)
> in javadoc production. Unclear if the javadoc output is materially affected.
> The following two files are:
> com/hp/hpl/jena/vocabulary/DAMLVocabulary.java
> com/hp/hpl/jena/vocabulary/DAML_OIL.java
> It's unclear as to whether DAML_OIL.java problems maybe due to implementing
> DAMLVocabulary and nothing more.
> /usr/lib/jvm/java-7-openjdk-amd64/bin/javadoc \
> -classpath fuseki-server.jar \ -- just a source of compiled Jena and
> all dependencies
> -encoding utf-8 \
> -d jdoc I.java
> The core problem is the form:
> -
> import com.hp.hpl.jena.rdf.model.Resource ;
> import com.hp.hpl.jena.rdf.model.Property ;
> public interface I
> {
> public Resource Property();
> }
> -
> where Property is a class and a method name, which is legal, it just breaks
> javadoc (standard doclet).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (JENA-333) Using javadoc 7 causes warning exception in build (DAMLVocabulary, DAML_OIL)
[
https://issues.apache.org/jira/browse/JENA-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Dickinson reassigned JENA-333:
--
Assignee: Ian Dickinson
> Using javadoc 7 causes warning exception in build (DAMLVocabulary, DAML_OIL)
>
>
> Key: JENA-333
> URL: https://issues.apache.org/jira/browse/JENA-333
> Project: Apache Jena
> Issue Type: Bug
> Components: Build, Onotology API
>Affects Versions: Jena 2.7.4
> Environment: Java 7 (1.7.0_07) Linux 64 bit. (but not Java 1.6.0_24)
>Reporter: Andy Seaborne
>Assignee: Ian Dickinson
>Priority: Minor
>
> Under java7, the build of jena core gets two stacktraces (marked as warning)
> in javadoc production. Unclear if the javadoc output is materially affected.
> The following two files are:
> com/hp/hpl/jena/vocabulary/DAMLVocabulary.java
> com/hp/hpl/jena/vocabulary/DAML_OIL.java
> It's unclear as to whether DAML_OIL.java problems maybe due to implementing
> DAMLVocabulary and nothing more.
> /usr/lib/jvm/java-7-openjdk-amd64/bin/javadoc \
> -classpath fuseki-server.jar \ -- just a source of compiled Jena and
> all dependencies
> -encoding utf-8 \
> -d jdoc I.java
> The core problem is the form:
> -
> import com.hp.hpl.jena.rdf.model.Resource ;
> import com.hp.hpl.jena.rdf.model.Property ;
> public interface I
> {
> public Resource Property();
> }
> -
> where Property is a class and a method name, which is legal, it just breaks
> javadoc (standard doclet).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-333) Using javadoc 7 causes warning exception in build (DAMLVocabulary, DAML_OIL)
[
https://issues.apache.org/jira/browse/JENA-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468485#comment-13468485
]
Ian Dickinson commented on JENA-333:
The rest of the DAML support is long gone in Jena, so I suggest these classes
get removed as soon as practicable. At the very least we should deprecate them
this cycle and remove them next cycle. In practice, I strongly doubt anyone
would notice if we just removed them now.
In the meantime, I would like to think that it would be possible to exclude a
certain class from Javadoc generation, but a quick look at the Maven javadoc
configuration page [1] suggests that you can only exclude by package name, not
by class.
[1] http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html
> Using javadoc 7 causes warning exception in build (DAMLVocabulary, DAML_OIL)
>
>
> Key: JENA-333
> URL: https://issues.apache.org/jira/browse/JENA-333
> Project: Apache Jena
> Issue Type: Bug
> Components: Build, Onotology API
>Affects Versions: Jena 2.7.4
> Environment: Java 7 (1.7.0_07) Linux 64 bit. (but not Java 1.6.0_24)
>Reporter: Andy Seaborne
>Priority: Minor
>
> Under java7, the build of jena core gets two stacktraces (marked as warning)
> in javadoc production. Unclear if the javadoc output is materially affected.
> The following two files are:
> com/hp/hpl/jena/vocabulary/DAMLVocabulary.java
> com/hp/hpl/jena/vocabulary/DAML_OIL.java
> It's unclear as to whether DAML_OIL.java problems maybe due to implementing
> DAMLVocabulary and nothing more.
> /usr/lib/jvm/java-7-openjdk-amd64/bin/javadoc \
> -classpath fuseki-server.jar \ -- just a source of compiled Jena and
> all dependencies
> -encoding utf-8 \
> -d jdoc I.java
> The core problem is the form:
> -
> import com.hp.hpl.jena.rdf.model.Resource ;
> import com.hp.hpl.jena.rdf.model.Property ;
> public interface I
> {
> public Resource Property();
> }
> -
> where Property is a class and a method name, which is legal, it just breaks
> javadoc (standard doclet).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JENA-285) rdfcat does not respect -n flag
Ian Dickinson created JENA-285: -- Summary: rdfcat does not respect -n flag Key: JENA-285 URL: https://issues.apache.org/jira/browse/JENA-285 Project: Apache Jena Issue Type: Bug Components: Cmd line tools Affects Versions: Jena 2.7.2 Reporter: Ian Dickinson -n flag (n-triples input syntax) is overridden by the file-extension guessing heuristics in the FileManager -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JENA-280) OntTools.nameHierarchyRoots gives wrong answer when reasoner attached
Ian Dickinson created JENA-280: -- Summary: OntTools.nameHierarchyRoots gives wrong answer when reasoner attached Key: JENA-280 URL: https://issues.apache.org/jira/browse/JENA-280 Project: Apache Jena Issue Type: Bug Components: Onotology API Reporter: Ian Dickinson Assignee: Ian Dickinson See https://gist.github.com/3143188 for setup -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JENA-278) Update maven information on website
[ https://issues.apache.org/jira/browse/JENA-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson resolved JENA-278. Resolution: Fixed Patch applied & published. Thank you! > Update maven information on website > --- > > Key: JENA-278 > URL: https://issues.apache.org/jira/browse/JENA-278 > Project: Apache Jena > Issue Type: Improvement > Components: Web site >Reporter: Laurent Pellegrino >Assignee: Ian Dickinson > Labels: maven, website > Attachments: maven.mdtext.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (JENA-278) Update maven information on website
[ https://issues.apache.org/jira/browse/JENA-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson reassigned JENA-278: -- Assignee: Ian Dickinson > Update maven information on website > --- > > Key: JENA-278 > URL: https://issues.apache.org/jira/browse/JENA-278 > Project: Apache Jena > Issue Type: Improvement > Components: Web site >Reporter: Laurent Pellegrino >Assignee: Ian Dickinson > Labels: maven, website > Attachments: maven.mdtext.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JENA-277) Can't navigate to manipulating_sparql_using_arq
[ https://issues.apache.org/jira/browse/JENA-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson resolved JENA-277. Resolution: Fixed Assignee: Ian Dickinson That article is on the query documentation index page already (http://jena.apache.org/documentation/query/index.html, 9th bullet under 'Introduction'). I've added a second link from the tutorials section. > Can't navigate to manipulating_sparql_using_arq > --- > > Key: JENA-277 > URL: https://issues.apache.org/jira/browse/JENA-277 > Project: Apache Jena > Issue Type: Improvement > Components: ARQ, Web site >Reporter: Andy Seaborne >Assignee: Ian Dickinson >Priority: Minor > > The article > http://jena.apache.org/documentation/query/manipulating_sparql_using_arq.html > isn't in the sidebar index nor the query documentation top level page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JENA-272) tdbloader2 shell script calls missing tdb_path
Ian Dickinson created JENA-272: -- Summary: tdbloader2 shell script calls missing tdb_path Key: JENA-272 URL: https://issues.apache.org/jira/browse/JENA-272 Project: Apache Jena Issue Type: Bug Components: TDB Affects Versions: Jena 2.7.2 Reporter: Ian Dickinson Priority: Minor [~/dev/java/apache-jena-2.7.2] ian@ian-desktop $ echo $JENA_HOME /home/ian/dev/java/apache-jena-2.7.2 [~/dev/java/apache-jena-2.7.2] ian@ian-desktop $ which tdbloader2 /home/ian/dev/java/apache-jena-2.7.2/bin/tdbloader2 [~/dev/java/apache-jena-2.7.2] ian@ian-desktop $ tdbloader2 /home/ian/dev/java/apache-jena-2.7.2/bin/tdbloader2: line 30: /home/ian/dev/java/apache-jena-2.7.2/bin/tdb_path: No such file or directory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JENA-263) Adding resource property inside TDB transaction causes message '******* UNEXPECTED'
Ian Dickinson created JENA-263: -- Summary: Adding resource property inside TDB transaction causes message '*** UNEXPECTED' Key: JENA-263 URL: https://issues.apache.org/jira/browse/JENA-263 Project: Apache Jena Issue Type: Bug Components: TDB Affects Versions: TDB 0.9.1 Reporter: Ian Dickinson I created the attached test case while trying to isolate a problem I was seeing in some other code. This code doesn't repro the exception I'm seeing, but I do get the output ' UNEXPECTED' on stderr. Test case attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JENA-263) Adding resource property inside TDB transaction causes message '******* UNEXPECTED'
[ https://issues.apache.org/jira/browse/JENA-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Dickinson updated JENA-263: --- Attachment: TdbTxText.java Minimal test case to reproduce 'UNEXPECTED' error message on stdout > Adding resource property inside TDB transaction causes message '*** > UNEXPECTED' > --- > > Key: JENA-263 > URL: https://issues.apache.org/jira/browse/JENA-263 > Project: Apache Jena > Issue Type: Bug > Components: TDB >Affects Versions: TDB 0.9.1 >Reporter: Ian Dickinson > Labels: tdb > Attachments: TdbTxText.java > > > I created the attached test case while trying to isolate a problem I was > seeing in some other code. This code doesn't repro the exception I'm seeing, > but I do get the output ' UNEXPECTED' on stderr. Test case > attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JENA-259) Add TDB classes to assembler defaults
Ian Dickinson created JENA-259: -- Summary: Add TDB classes to assembler defaults Key: JENA-259 URL: https://issues.apache.org/jira/browse/JENA-259 Project: Apache Jena Issue Type: Improvement Components: Jena Reporter: Ian Dickinson Priority: Minor Now that TDB is shipped as part of the Jena single download, it would be nice if Assemblers would recognize TDB functionality by default. At present, it's necessary to use the loadClass extension mechanism as described on http://jena.apache.org/documentation/tdb/assembler.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JENA-245) Many links on http://jena.apache.org/ don't work
[
https://issues.apache.org/jira/browse/JENA-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274329#comment-13274329
]
Ian Dickinson commented on JENA-245:
Hmm. I thought I had run a search for /jena when I did the migration. Oh well.
I'm running a link checker now, which I have been meaning to to for ages.
Taking a while though - there's a *lot* of JavaDoc.
> Many links on http://jena.apache.org/ don't work
>
>
> Key: JENA-245
> URL: https://issues.apache.org/jira/browse/JENA-245
> Project: Apache Jena
> Issue Type: Bug
> Components: Web site
>Reporter: Hans Hübner
>Assignee: Paolo Castagna
>
> The links on the project home page http://jena.apache.org/ ("I want to...")
> all don't work. It seems that there is a problem with the base URL setting
> or something.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
