[jira] [Commented] (JENA-1766) Fuseki Web interface endpoint mechanism not working

2019-09-30 Thread Andy Seaborne (Jira)


[ 
https://issues.apache.org/jira/browse/JENA-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16941339#comment-16941339
 ] 

Andy Seaborne commented on JENA-1766:
-

Thanks - that works as well (give or take having to force reload of the JS when 
using Firefox).


> Fuseki Web interface endpoint mechanism not working
> ---
>
> Key: JENA-1766
> URL: https://issues.apache.org/jira/browse/JENA-1766
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.13.0
>Reporter: Elie Roux
>Priority: Major
> Attachments: core.ttl
>
>
> Using the new 3.13.0 Fuseki, I'm getting a bug in the web interface, the 
> "SPARQL ENDPOINT" is empty in the query interface.
>  
> After a bit of debugging, I believe this is due to a difference returned by 
> {{/fuseki/$/server}}: it used to return non-lower case values for 
> {{srv.type}}, for instance with Fuseki 3.12.0:
> {noformat}
> {
> "version" : "3.13.0-SNAPSHOT" ,
> "built" : "2019-07-17T09:12:45+" ,
> "startDateTime" : "2019-09-27T16:18:34.271+00:00" ,
> "uptime" : 163057 ,
>     "datasets" : [
>   {
>     "ds.name" : "/corerw" ,
>     "ds.state" : true ,
>         "ds.services" : [
> {
>    "srv.type" : "GSP_RW" ,
>    "srv.description" : "Graph Store Protocol" ,
>    "srv.endpoints" : [ "data" ]
>    } ,
>    {
>    "srv.type" : "Upload" ,
>    "srv.description" : "File Upload" ,
>   "srv.endpoints" : [ "upload" ]
>    } ,
>          {
>   "srv.type" : "Query" ,
>   "srv.description" : "SPARQL Query" ,
>   "srv.endpoints" : [ "query" ]
>    } ,
>        {
>   "srv.type" : "Update" ,
>   "srv.description" : "SPARQL Update" ,
>   "srv.endpoints" : [ "update" ]
>        }
>  ]
>     }
>   ]
>  }
> }
> {noformat}
> While with Fuseki 3.13.0, with an equivalent configuration, the returned json 
> is:
>  
> {noformat}
>   "version" : "3.13.0" ,
>   "built" : "2019-09-25T15:01:44+" ,
>   "startDateTime" : "2019-09-29T12:46:11.353+00:00" ,
>   "uptime" : 3025 ,
>   "datasets" : [
>     {
>   "ds.name" : "/corerw" ,
>   "ds.state" : true ,
>       "ds.services" : [
>         {
>   "srv.type" : "gsp-rw" ,
>           "srv.description" : "Graph Store Protocol" ,
>           "srv.endpoints" : [ "data" ]
>         } ,
>        {
>           "srv.type" : "query" ,
>           "srv.description" : "SPARQL Query" ,
>           "srv.endpoints" : [ "query" ]
>         } ,
>        {
>           "srv.type" : "update" ,
>           "srv.description" : "SPARQL Update" ,
>           "srv.endpoints" : [ "update" ]
>         } ,
>        {
>           "srv.type" : "upload" ,
>           "srv.description" : "File Upload" ,
>           "srv.endpoints" : [ "upload" ]
>         {
>       ]
>    }
>   ]
> }
> {noformat}
> where srv.type is all lower-case. This doesn't play well with the JavaScript 
> code that compared against non-lowercase values, see for instance
>  
> [https://github.com/apache/jena/blob/master/jena-fuseki2/jena-fuseki-webapp/src/main/webapp/js/app/models/dataset.js#L122]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (JENA-909) Create Docker launcher for Fuseki

2019-09-30 Thread Claude Warren (Jira)


[ 
https://issues.apache.org/jira/browse/JENA-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16941283#comment-16941283
 ] 

Claude Warren commented on JENA-909:


Would it make sense to put the maven docker build stuff into an project in 
Extras (I'm always looking for companionship for QueryBuilder).  I think this 
is useful but not mainline code.  Also, there is a maven plugin that will use 
the standard docker.yml file to build the image.  We could tag the image is 
snapshot and have the release build/deploy the real release version.

I have built Maven poms that work this way at work.  We basically push to a 
snapshot docker respoitory on nightly and production level repository on 
release.

[~stain] [~graphity] do either of you feel like your packaging could work this 
way?

> Create Docker launcher for Fuseki
> -
>
> Key: JENA-909
> URL: https://issues.apache.org/jira/browse/JENA-909
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki
>Reporter: Andy Seaborne
>Priority: Major
>
> Provide a Docker launcher and setup documentation for  Fuseki2.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [jena] afs opened a new pull request #615: JENA 1766: Fuseki Web interface endpoint fix

2019-09-30 Thread GitBox
afs opened a new pull request #615: JENA 1766:  Fuseki Web interface endpoint 
fix
URL: https://github.com/apache/jena/pull/615
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (JENA-1766) Fuseki Web interface endpoint mechanism not working

2019-09-30 Thread Elie Roux (Jira)


[ 
https://issues.apache.org/jira/browse/JENA-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16941118#comment-16941118
 ] 

Elie Roux commented on JENA-1766:
-

sure, I just attached it. It's really nothing special except for the analyzers 
that you should probably remove (they necessitate some external jars)

> Fuseki Web interface endpoint mechanism not working
> ---
>
> Key: JENA-1766
> URL: https://issues.apache.org/jira/browse/JENA-1766
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.13.0
>Reporter: Elie Roux
>Priority: Major
> Attachments: core.ttl
>
>
> Using the new 3.13.0 Fuseki, I'm getting a bug in the web interface, the 
> "SPARQL ENDPOINT" is empty in the query interface.
>  
> After a bit of debugging, I believe this is due to a difference returned by 
> {{/fuseki/$/server}}: it used to return non-lower case values for 
> {{srv.type}}, for instance with Fuseki 3.12.0:
> {noformat}
> {
> "version" : "3.13.0-SNAPSHOT" ,
> "built" : "2019-07-17T09:12:45+" ,
> "startDateTime" : "2019-09-27T16:18:34.271+00:00" ,
> "uptime" : 163057 ,
>     "datasets" : [
>   {
>     "ds.name" : "/corerw" ,
>     "ds.state" : true ,
>         "ds.services" : [
> {
>    "srv.type" : "GSP_RW" ,
>    "srv.description" : "Graph Store Protocol" ,
>    "srv.endpoints" : [ "data" ]
>    } ,
>    {
>    "srv.type" : "Upload" ,
>    "srv.description" : "File Upload" ,
>   "srv.endpoints" : [ "upload" ]
>    } ,
>          {
>   "srv.type" : "Query" ,
>   "srv.description" : "SPARQL Query" ,
>   "srv.endpoints" : [ "query" ]
>    } ,
>        {
>   "srv.type" : "Update" ,
>   "srv.description" : "SPARQL Update" ,
>   "srv.endpoints" : [ "update" ]
>        }
>  ]
>     }
>   ]
>  }
> }
> {noformat}
> While with Fuseki 3.13.0, with an equivalent configuration, the returned json 
> is:
>  
> {noformat}
>   "version" : "3.13.0" ,
>   "built" : "2019-09-25T15:01:44+" ,
>   "startDateTime" : "2019-09-29T12:46:11.353+00:00" ,
>   "uptime" : 3025 ,
>   "datasets" : [
>     {
>   "ds.name" : "/corerw" ,
>   "ds.state" : true ,
>       "ds.services" : [
>         {
>   "srv.type" : "gsp-rw" ,
>           "srv.description" : "Graph Store Protocol" ,
>           "srv.endpoints" : [ "data" ]
>         } ,
>        {
>           "srv.type" : "query" ,
>           "srv.description" : "SPARQL Query" ,
>           "srv.endpoints" : [ "query" ]
>         } ,
>        {
>           "srv.type" : "update" ,
>           "srv.description" : "SPARQL Update" ,
>           "srv.endpoints" : [ "update" ]
>         } ,
>        {
>           "srv.type" : "upload" ,
>           "srv.description" : "File Upload" ,
>           "srv.endpoints" : [ "upload" ]
>         {
>       ]
>    }
>   ]
> }
> {noformat}
> where srv.type is all lower-case. This doesn't play well with the JavaScript 
> code that compared against non-lowercase values, see for instance
>  
> [https://github.com/apache/jena/blob/master/jena-fuseki2/jena-fuseki-webapp/src/main/webapp/js/app/models/dataset.js#L122]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (JENA-1766) Fuseki Web interface endpoint mechanism not working

2019-09-30 Thread Elie Roux (Jira)


 [ 
https://issues.apache.org/jira/browse/JENA-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Elie Roux updated JENA-1766:

Attachment: core.ttl

> Fuseki Web interface endpoint mechanism not working
> ---
>
> Key: JENA-1766
> URL: https://issues.apache.org/jira/browse/JENA-1766
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.13.0
>Reporter: Elie Roux
>Priority: Major
> Attachments: core.ttl
>
>
> Using the new 3.13.0 Fuseki, I'm getting a bug in the web interface, the 
> "SPARQL ENDPOINT" is empty in the query interface.
>  
> After a bit of debugging, I believe this is due to a difference returned by 
> {{/fuseki/$/server}}: it used to return non-lower case values for 
> {{srv.type}}, for instance with Fuseki 3.12.0:
> {noformat}
> {
> "version" : "3.13.0-SNAPSHOT" ,
> "built" : "2019-07-17T09:12:45+" ,
> "startDateTime" : "2019-09-27T16:18:34.271+00:00" ,
> "uptime" : 163057 ,
>     "datasets" : [
>   {
>     "ds.name" : "/corerw" ,
>     "ds.state" : true ,
>         "ds.services" : [
> {
>    "srv.type" : "GSP_RW" ,
>    "srv.description" : "Graph Store Protocol" ,
>    "srv.endpoints" : [ "data" ]
>    } ,
>    {
>    "srv.type" : "Upload" ,
>    "srv.description" : "File Upload" ,
>   "srv.endpoints" : [ "upload" ]
>    } ,
>          {
>   "srv.type" : "Query" ,
>   "srv.description" : "SPARQL Query" ,
>   "srv.endpoints" : [ "query" ]
>    } ,
>        {
>   "srv.type" : "Update" ,
>   "srv.description" : "SPARQL Update" ,
>   "srv.endpoints" : [ "update" ]
>        }
>  ]
>     }
>   ]
>  }
> }
> {noformat}
> While with Fuseki 3.13.0, with an equivalent configuration, the returned json 
> is:
>  
> {noformat}
>   "version" : "3.13.0" ,
>   "built" : "2019-09-25T15:01:44+" ,
>   "startDateTime" : "2019-09-29T12:46:11.353+00:00" ,
>   "uptime" : 3025 ,
>   "datasets" : [
>     {
>   "ds.name" : "/corerw" ,
>   "ds.state" : true ,
>       "ds.services" : [
>         {
>   "srv.type" : "gsp-rw" ,
>           "srv.description" : "Graph Store Protocol" ,
>           "srv.endpoints" : [ "data" ]
>         } ,
>        {
>           "srv.type" : "query" ,
>           "srv.description" : "SPARQL Query" ,
>           "srv.endpoints" : [ "query" ]
>         } ,
>        {
>           "srv.type" : "update" ,
>           "srv.description" : "SPARQL Update" ,
>           "srv.endpoints" : [ "update" ]
>         } ,
>        {
>           "srv.type" : "upload" ,
>           "srv.description" : "File Upload" ,
>           "srv.endpoints" : [ "upload" ]
>         {
>       ]
>    }
>   ]
> }
> {noformat}
> where srv.type is all lower-case. This doesn't play well with the JavaScript 
> code that compared against non-lowercase values, see for instance
>  
> [https://github.com/apache/jena/blob/master/jena-fuseki2/jena-fuseki-webapp/src/main/webapp/js/app/models/dataset.js#L122]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (JENA-1766) Fuseki Web interface endpoint mechanism not working

2019-09-30 Thread Andy Seaborne (Jira)


[ 
https://issues.apache.org/jira/browse/JENA-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16941110#comment-16941110
 ] 

Andy Seaborne commented on JENA-1766:
-

[~eroux] What's the configuration file for your setup? I have a fix for the 
default configuration, but if I can test with yours that would be good.

> Fuseki Web interface endpoint mechanism not working
> ---
>
> Key: JENA-1766
> URL: https://issues.apache.org/jira/browse/JENA-1766
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.13.0
>Reporter: Elie Roux
>Priority: Major
>
> Using the new 3.13.0 Fuseki, I'm getting a bug in the web interface, the 
> "SPARQL ENDPOINT" is empty in the query interface.
>  
> After a bit of debugging, I believe this is due to a difference returned by 
> {{/fuseki/$/server}}: it used to return non-lower case values for 
> {{srv.type}}, for instance with Fuseki 3.12.0:
> {noformat}
> {
> "version" : "3.13.0-SNAPSHOT" ,
> "built" : "2019-07-17T09:12:45+" ,
> "startDateTime" : "2019-09-27T16:18:34.271+00:00" ,
> "uptime" : 163057 ,
>     "datasets" : [
>   {
>     "ds.name" : "/corerw" ,
>     "ds.state" : true ,
>         "ds.services" : [
> {
>    "srv.type" : "GSP_RW" ,
>    "srv.description" : "Graph Store Protocol" ,
>    "srv.endpoints" : [ "data" ]
>    } ,
>    {
>    "srv.type" : "Upload" ,
>    "srv.description" : "File Upload" ,
>   "srv.endpoints" : [ "upload" ]
>    } ,
>          {
>   "srv.type" : "Query" ,
>   "srv.description" : "SPARQL Query" ,
>   "srv.endpoints" : [ "query" ]
>    } ,
>        {
>   "srv.type" : "Update" ,
>   "srv.description" : "SPARQL Update" ,
>   "srv.endpoints" : [ "update" ]
>        }
>  ]
>     }
>   ]
>  }
> }
> {noformat}
> While with Fuseki 3.13.0, with an equivalent configuration, the returned json 
> is:
>  
> {noformat}
>   "version" : "3.13.0" ,
>   "built" : "2019-09-25T15:01:44+" ,
>   "startDateTime" : "2019-09-29T12:46:11.353+00:00" ,
>   "uptime" : 3025 ,
>   "datasets" : [
>     {
>   "ds.name" : "/corerw" ,
>   "ds.state" : true ,
>       "ds.services" : [
>         {
>   "srv.type" : "gsp-rw" ,
>           "srv.description" : "Graph Store Protocol" ,
>           "srv.endpoints" : [ "data" ]
>         } ,
>        {
>           "srv.type" : "query" ,
>           "srv.description" : "SPARQL Query" ,
>           "srv.endpoints" : [ "query" ]
>         } ,
>        {
>           "srv.type" : "update" ,
>           "srv.description" : "SPARQL Update" ,
>           "srv.endpoints" : [ "update" ]
>         } ,
>        {
>           "srv.type" : "upload" ,
>           "srv.description" : "File Upload" ,
>           "srv.endpoints" : [ "upload" ]
>         {
>       ]
>    }
>   ]
> }
> {noformat}
> where srv.type is all lower-case. This doesn't play well with the JavaScript 
> code that compared against non-lowercase values, see for instance
>  
> [https://github.com/apache/jena/blob/master/jena-fuseki2/jena-fuseki-webapp/src/main/webapp/js/app/models/dataset.js#L122]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


Towards Jena 3.13.1

2019-09-30 Thread Andy Seaborne
See the vote thread for 3.13.0 RC2 - the automatic module names for some 
modules are wrong. Aaron has fixed this but the release will interact 
badly with Java module usage.


As well as the automatic module names, there is now JENA-1766 (problems, 
and solution, with the Fuseki admin UI).  This is in the SNAPSHOT builds 
for testing.


I think it is better to wait a few days at least to see if anything else 
comes up but otherwise I'm hoping for getting this out sooner rather 
than later.


The master branch is still 3.14.0-SNAPSHOT - to make this a proper 
x.x.1, could people hold off from merging anything that aren't bug fixes.


If it turns out to be a longer wait, we can branch and release from the 
branch but if we can leave the version flip until the last moment (so a 
few hours of reverted version), do it on master and release from master 
then master has the release history.


Andy


[jira] [Commented] (JENA-1766) Fuseki Web interface endpoint mechanism not working

2019-09-30 Thread Andy Seaborne (Jira)


[ 
https://issues.apache.org/jira/browse/JENA-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940853#comment-16940853
 ] 

Andy Seaborne commented on JENA-1766:
-

@eroux - thanks for the report and investigation. 

There has been a server side change not reflected in the UI-side. It also 
affects the stats and the metrics output.

There are different details in 3.13 stats anyway, mainly because (bug) 
previously a JSON object entry was being overwritten.

Also, the "quads" and GSP become the same operation. "quads" is now a GSP 
extension rather than a sort-of-extension special-case.


> Fuseki Web interface endpoint mechanism not working
> ---
>
> Key: JENA-1766
> URL: https://issues.apache.org/jira/browse/JENA-1766
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.13.0
>Reporter: Elie Roux
>Priority: Major
>
> Using the new 3.13.0 Fuseki, I'm getting a bug in the web interface, the 
> "SPARQL ENDPOINT" is empty in the query interface.
>  
> After a bit of debugging, I believe this is due to a difference returned by 
> {{/fuseki/$/server}}: it used to return non-lower case values for 
> {{srv.type}}, for instance with Fuseki 3.12.0:
> {noformat}
> {
> "version" : "3.13.0-SNAPSHOT" ,
> "built" : "2019-07-17T09:12:45+" ,
> "startDateTime" : "2019-09-27T16:18:34.271+00:00" ,
> "uptime" : 163057 ,
>     "datasets" : [
>   {
>     "ds.name" : "/corerw" ,
>     "ds.state" : true ,
>         "ds.services" : [
> {
>    "srv.type" : "GSP_RW" ,
>    "srv.description" : "Graph Store Protocol" ,
>    "srv.endpoints" : [ "data" ]
>    } ,
>    {
>    "srv.type" : "Upload" ,
>    "srv.description" : "File Upload" ,
>   "srv.endpoints" : [ "upload" ]
>    } ,
>          {
>   "srv.type" : "Query" ,
>   "srv.description" : "SPARQL Query" ,
>   "srv.endpoints" : [ "query" ]
>    } ,
>        {
>   "srv.type" : "Update" ,
>   "srv.description" : "SPARQL Update" ,
>   "srv.endpoints" : [ "update" ]
>        }
>  ]
>     }
>   ]
>  }
> }
> {noformat}
> While with Fuseki 3.13.0, with an equivalent configuration, the returned json 
> is:
>  
> {noformat}
>   "version" : "3.13.0" ,
>   "built" : "2019-09-25T15:01:44+" ,
>   "startDateTime" : "2019-09-29T12:46:11.353+00:00" ,
>   "uptime" : 3025 ,
>   "datasets" : [
>     {
>   "ds.name" : "/corerw" ,
>   "ds.state" : true ,
>       "ds.services" : [
>         {
>   "srv.type" : "gsp-rw" ,
>           "srv.description" : "Graph Store Protocol" ,
>           "srv.endpoints" : [ "data" ]
>         } ,
>        {
>           "srv.type" : "query" ,
>           "srv.description" : "SPARQL Query" ,
>           "srv.endpoints" : [ "query" ]
>         } ,
>        {
>           "srv.type" : "update" ,
>           "srv.description" : "SPARQL Update" ,
>           "srv.endpoints" : [ "update" ]
>         } ,
>        {
>           "srv.type" : "upload" ,
>           "srv.description" : "File Upload" ,
>           "srv.endpoints" : [ "upload" ]
>         {
>       ]
>    }
>   ]
> }
> {noformat}
> where srv.type is all lower-case. This doesn't play well with the JavaScript 
> code that compared against non-lowercase values, see for instance
>  
> [https://github.com/apache/jena/blob/master/jena-fuseki2/jena-fuseki-webapp/src/main/webapp/js/app/models/dataset.js#L122]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [jena] afs opened a new pull request #614: Compatibility

2019-09-30 Thread GitBox
afs opened a new pull request #614: Compatibility
URL: https://github.com/apache/jena/pull/614
 
 
   2 small compatibility adjustments in non-API code.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (JENA-1764) Fix missing and duplicate Automatic-Module-Name metadata

2019-09-30 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/JENA-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940813#comment-16940813
 ] 

ASF subversion and git services commented on JENA-1764:
---

Commit f1a1f6d7bf4f9a2a9f32fbf4d653f19422ebacae in jena's branch 
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=f1a1f6d ]

Merge pull request #612 from apache/JENA-1764

JENA-1764: Fix Automatic-Module-Name metadata

> Fix missing and duplicate Automatic-Module-Name metadata
> 
>
> Key: JENA-1764
> URL: https://issues.apache.org/jira/browse/JENA-1764
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.12.0
> Environment: Using Jena on Java11 when Jena artifacts are on the 
> module path (rather than the class path)
>Reporter: Aaron Coburn
>Assignee: Aaron Coburn
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The Java9+ module system makes use of the MANIFEST header: 
> Automatic-Module-Name. This header is optional, but if present it needs to be 
> globally unique and must follow certain formatting rules (e.g. no hyphens).
> The Automatic-Module-Name header in the jena-dboe-storage artifact is empty 
> (not missing), which is invalid.
> In addition, the various jena-elephas-* and jena-jdbc-* artifacts contain 
> duplicate module name declarations
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (JENA-1764) Fix missing and duplicate Automatic-Module-Name metadata

2019-09-30 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/JENA-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940811#comment-16940811
 ] 

ASF subversion and git services commented on JENA-1764:
---

Commit 55218eb69b4bd781a48928ec3e370515c9ca6536 in jena's branch 
refs/heads/master from Aaron Coburn
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=55218eb ]

JENA-1764: Fix Automatic-Module-Name metadata


> Fix missing and duplicate Automatic-Module-Name metadata
> 
>
> Key: JENA-1764
> URL: https://issues.apache.org/jira/browse/JENA-1764
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.12.0
> Environment: Using Jena on Java11 when Jena artifacts are on the 
> module path (rather than the class path)
>Reporter: Aaron Coburn
>Assignee: Aaron Coburn
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The Java9+ module system makes use of the MANIFEST header: 
> Automatic-Module-Name. This header is optional, but if present it needs to be 
> globally unique and must follow certain formatting rules (e.g. no hyphens).
> The Automatic-Module-Name header in the jena-dboe-storage artifact is empty 
> (not missing), which is invalid.
> In addition, the various jena-elephas-* and jena-jdbc-* artifacts contain 
> duplicate module name declarations
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (JENA-1764) Fix missing and duplicate Automatic-Module-Name metadata

2019-09-30 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/JENA-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940812#comment-16940812
 ] 

ASF subversion and git services commented on JENA-1764:
---

Commit f1a1f6d7bf4f9a2a9f32fbf4d653f19422ebacae in jena's branch 
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=f1a1f6d ]

Merge pull request #612 from apache/JENA-1764

JENA-1764: Fix Automatic-Module-Name metadata

> Fix missing and duplicate Automatic-Module-Name metadata
> 
>
> Key: JENA-1764
> URL: https://issues.apache.org/jira/browse/JENA-1764
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.12.0
> Environment: Using Jena on Java11 when Jena artifacts are on the 
> module path (rather than the class path)
>Reporter: Aaron Coburn
>Assignee: Aaron Coburn
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The Java9+ module system makes use of the MANIFEST header: 
> Automatic-Module-Name. This header is optional, but if present it needs to be 
> globally unique and must follow certain formatting rules (e.g. no hyphens).
> The Automatic-Module-Name header in the jena-dboe-storage artifact is empty 
> (not missing), which is invalid.
> In addition, the various jena-elephas-* and jena-jdbc-* artifacts contain 
> duplicate module name declarations
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[GitHub] [jena] afs merged pull request #612: JENA-1764: Fix Automatic-Module-Name metadata

2019-09-30 Thread GitBox
afs merged pull request #612: JENA-1764: Fix Automatic-Module-Name metadata
URL: https://github.com/apache/jena/pull/612
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [jena] afs opened a new pull request #613: Improve some comments

2019-09-30 Thread GitBox
afs opened a new pull request #613: Improve some comments
URL: https://github.com/apache/jena/pull/613
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (JENA-1704) Enable Apache Sonar reports

2019-09-30 Thread Claude Warren (Jira)


[ 
https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940803#comment-16940803
 ] 

Claude Warren commented on JENA-1704:
-

My reading of 
https://docs.sonarqube.org/latest/architecture/architecture-integration/ is 
that we would have to run SonarScanner as part of the build process for the 
sonar service ( SonarQube Server  and  SonarQube Database) to report it. 

We could do this as part of the site processing and just add site processing to 
the nightly build.  I think this would give us the speed we like for 
development, a nightly or on-demand report of the state of the code base as 
well as SonarQube reports.

I could be wrong about all of the above.

> Enable Apache Sonar reports
> ---
>
> Key: JENA-1704
> URL: https://issues.apache.org/jira/browse/JENA-1704
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Build
>Reporter: Adam Soroka
>Assignee: Adam Soroka
>Priority: Trivial
>
> Apache offers a Sonar service at [https://builds.apache.org/analysis.] We 
> should take advantage of it in a non-intrusive way. Enabling Sonar analysis 
> must not annoy anyone working on the codebase or make development less 
> pleasant, so it must be done carefully.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (JENA-1704) Enable Apache Sonar reports

2019-09-30 Thread Andy Seaborne (Jira)


[ 
https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940795#comment-16940795
 ] 

Andy Seaborne commented on JENA-1704:
-

Claude - INFRA run a sonar service. This means it is always available and 
updated.


> Enable Apache Sonar reports
> ---
>
> Key: JENA-1704
> URL: https://issues.apache.org/jira/browse/JENA-1704
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Build
>Reporter: Adam Soroka
>Assignee: Adam Soroka
>Priority: Trivial
>
> Apache offers a Sonar service at [https://builds.apache.org/analysis.] We 
> should take advantage of it in a non-intrusive way. Enabling Sonar analysis 
> must not annoy anyone working on the codebase or make development less 
> pleasant, so it must be done carefully.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (JENA-1704) Enable Apache Sonar reports

2019-09-30 Thread Claude Warren (Jira)


[ 
https://issues.apache.org/jira/browse/JENA-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940776#comment-16940776
 ] 

Claude Warren commented on JENA-1704:
-

If Sonar were added to the site build then it (along with the other reports) 
could be generated on demand.

I have a pre latest release branch (I will update to latest head soon) that 
builds most of the standard reports across the entire set of packages. 
(https://github.com/Claudenw/jena/tree/mavenise-site)  on my github jena on the 
mavenise-site branch. 

Claude

> Enable Apache Sonar reports
> ---
>
> Key: JENA-1704
> URL: https://issues.apache.org/jira/browse/JENA-1704
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Build
>Reporter: Adam Soroka
>Assignee: Adam Soroka
>Priority: Trivial
>
> Apache offers a Sonar service at [https://builds.apache.org/analysis.] We 
> should take advantage of it in a non-intrusive way. Enabling Sonar analysis 
> must not annoy anyone working on the codebase or make development less 
> pleasant, so it must be done carefully.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)