[jira] [Commented] (COMMONSRDF-55) Stream of Jena quads use wrong IRI for default graph

2017-02-02 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850501#comment-15850501
 ] 

ASF GitHub Bot commented on COMMONSRDF-55:
--

Github user ajs6f commented on the issue:

https://github.com/apache/commons-rdf/pull/32
  
I suppose I incline to (2) right now. The "magic" URIs are entirely 
Jena-specific, so ideally they appear as few places outside of Jena code itself 
as possible. On the other hand, `Quad.isDefaultGraph()` (the instance member, 
not the static function that takes a `Node`) seems like the most-encapsulated, 
best-segregated test.


> Stream of Jena quads use wrong IRI for default graph
> 
>
> Key: COMMONSRDF-55
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-55
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: jena
>Affects Versions: 0.3.0
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
> Fix For: 1.0.0
>
>
> See https://travis-ci.org/apache/commons-rdf/builds/195548479
> {code}
> org.apache.commons.rdf.jena.DatasetJenaTest
> streamLanguageTagsCaseInsensitive(org.apache.commons.rdf.jena.DatasetJenaTest)
>   Time elapsed: 0.012 sec  <<< FAILURE!
> java.lang.AssertionError: expected:< 
>  "Hello"@EN-GB .> but 
> was:<  "Hello"@en-GB .>
> {code}
> Jena uses the IRI `` internally to represent the 
> default graph within datasets - we need to recognize that on the way out of a 
> `JenaDatasetImpl.stream()` and possibly in the `asQuad(JenaQuad)` converter 
> and replace it with `Optional.empty()` so the default graph appears the same 
> across implementations.
> The `AbstractDatasetTest`  should be augmented to do more tests on the 
> default graph, including `.stream()`, `.iterate()`, `.contains()` and 
> `.remove()`1.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (CONFIGURATION-651) Configuration 2 does not declare optional imports in OSGI correctly

2017-02-02 Thread Fabian Lange (JIRA) 

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

Fabian Lange closed CONFIGURATION-651.
--
Resolution: Fixed

> Configuration 2 does not declare optional imports in OSGI correctly
> ---
>
> Key: CONFIGURATION-651
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-651
> Project: Commons Configuration
>  Issue Type: Bug
>Reporter: Fabian Lange
>
> osgi.identity=org.apache.commons.configuration; type=osgi.bundle; 
> version="[2.1.0,2.1.0]"; resolution:=mandatory [caused by: Unable to resolve 
> org.apache.commons.configuration/2.1.0: missing requirement 
> [org.apache.commons.configuration/2.1.0] osgi.wiring.package; 
> filter:="(osgi.wiring.package=org.springframework.beans.factory)"]]]
> according to the pom it is optional, but its not marked as optional in the 
> bundle.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CONFIGURATION-651) Configuration 2 does not declare optional imports in OSGI correctly

2017-02-02 Thread Fabian Lange (JIRA) 

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850472#comment-15850472
 ] 

Fabian Lange commented on CONFIGURATION-651:


correct, sorry for the noise, need to improve my jira issue finding skills :)

> Configuration 2 does not declare optional imports in OSGI correctly
> ---
>
> Key: CONFIGURATION-651
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-651
> Project: Commons Configuration
>  Issue Type: Bug
>Reporter: Fabian Lange
>
> osgi.identity=org.apache.commons.configuration; type=osgi.bundle; 
> version="[2.1.0,2.1.0]"; resolution:=mandatory [caused by: Unable to resolve 
> org.apache.commons.configuration/2.1.0: missing requirement 
> [org.apache.commons.configuration/2.1.0] osgi.wiring.package; 
> filter:="(osgi.wiring.package=org.springframework.beans.factory)"]]]
> according to the pom it is optional, but its not marked as optional in the 
> bundle.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] commons-lang issue #231: Evaluate Architecure

2017-02-02 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/231
  

[![Coverage 
Status](https://coveralls.io/builds/9969109/badge)](https://coveralls.io/builds/9969109)

Coverage increased (+0.0007%) to 94.456% when pulling 
**13df6b084b0ac64e291d10f7ecdb4dc85e7cde91 on Tomschi:master** into 
**ab25f67348d4885620df86497889c1826f013a73 on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] commons-lang pull request #231: Evaluate Architecure

2017-02-02 Thread Tomschi 
GitHub user Tomschi opened a pull request:

https://github.com/apache/commons-lang/pull/231

Evaluate Architecure

Add static field for hardware architecure.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Tomschi/commons-lang master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/231.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #231


commit 13df6b084b0ac64e291d10f7ecdb4dc85e7cde91
Author: Tomschi 
Date:   2017-02-02T20:29:39Z

Add boolean variables for evaluating architecture.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (CONFIGURATION-651) Configuration 2 does not declare optional imports in OSGI correctly

2017-02-02 Thread Oliver Heger (JIRA) 

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850428#comment-15850428
 ] 

Oliver Heger commented on CONFIGURATION-651:


I think this has already been fixed in trunk. The problem had been reported in 
CONFIGURATION-639. Can you verify if this solves your problem?

> Configuration 2 does not declare optional imports in OSGI correctly
> ---
>
> Key: CONFIGURATION-651
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-651
> Project: Commons Configuration
>  Issue Type: Bug
>Reporter: Fabian Lange
>
> osgi.identity=org.apache.commons.configuration; type=osgi.bundle; 
> version="[2.1.0,2.1.0]"; resolution:=mandatory [caused by: Unable to resolve 
> org.apache.commons.configuration/2.1.0: missing requirement 
> [org.apache.commons.configuration/2.1.0] osgi.wiring.package; 
> filter:="(osgi.wiring.package=org.springframework.beans.factory)"]]]
> according to the pom it is optional, but its not marked as optional in the 
> bundle.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (FILEUPLOAD-280) File Upload fails to recognize RFC 7578-compliant filename

2017-02-02 Thread Michael Osipov (JIRA) 

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850417#comment-15850417
 ] 

Michael Osipov commented on FILEUPLOAD-280:
---

Header says {{PROPOSED STANDARD}} how likely is a pass of this RFC?

> File Upload fails to recognize RFC 7578-compliant filename
> --
>
> Key: FILEUPLOAD-280
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-280
> Project: Commons FileUpload
>  Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Miroslav Holubec
>
> [RFC-7578|https://tools.ietf.org/html/rfc7578] which obsoletes RFC-2388 
> (together with RFC-2047), 
> [defines|https://tools.ietf.org/html/rfc7578#section-4.2] new encoding for 
> filenames inside HTTP payload, so called percent encoding, known already from 
> URI.
> Commons Fileupload should support it together with old 
> [RFC-2047|https://tools.ietf.org/html/rfc2047].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CONFIGURATION-651) Configuration 2 does not declare optional imports in OSGI correctly

2017-02-02 Thread Fabian Lange (JIRA) 
Fabian Lange created CONFIGURATION-651:
--

 Summary: Configuration 2 does not declare optional imports in OSGI 
correctly
 Key: CONFIGURATION-651
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-651
 Project: Commons Configuration
  Issue Type: Bug
Reporter: Fabian Lange


osgi.identity=org.apache.commons.configuration; type=osgi.bundle; 
version="[2.1.0,2.1.0]"; resolution:=mandatory [caused by: Unable to resolve 
org.apache.commons.configuration/2.1.0: missing requirement 
[org.apache.commons.configuration/2.1.0] osgi.wiring.package; 
filter:="(osgi.wiring.package=org.springframework.beans.factory)"]]]

according to the pom it is optional, but its not marked as optional in the 
bundle.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (COMMONSRDF-55) Stream of Jena quads use wrong IRI for default graph

2017-02-02 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850251#comment-15850251
 ] 

ASF GitHub Bot commented on COMMONSRDF-55:
--

Github user stain commented on the issue:

https://github.com/apache/commons-rdf/pull/32
  
The Commons RDF marker for the default graph (as of today) is 
`Optional.empty()` and not an `RDFNode` (and thus can only be used in the 
`Quad.getGraphName()` position).

There are four boundaries that can create Commons RDF Quad instances from 
Jena:

* **Retrieving:** 
[Dataset.stream()](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/api/Dataset.html#stream--),
 `.iterate()` and friends
* **Adapting:** 
[JenaRDF.asQuad(jenaQuad)](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/jena/JenaRDF.html#asQuad-org.apache.jena.sparql.core.Quad-)
* **Creating:** 
[JenaRDF](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/jena/JenaRDF.html#createQuad-org.apache.commons.rdf.api.BlankNodeOrIRI-org.apache.commons.rdf.api.BlankNodeOrIRI-org.apache.commons.rdf.api.IRI-org.apache.commons.rdf.api.RDFTerm-)
  with a graph `IRI` adapted from a Node using 
[JenaRDF.asRDFTerm(Quad.defaultGraph)](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/jena/JenaRDF.html#asRDFTerm-org.apache.jena.graph.Node-)
  *  ..in worst case, `IRI` from `RDF.createIRI("urn:x-arq:DefaultGraph")
* **Parsing:** JenaRDFParser - which uses JenaRDF.asQuad (experimental)

I think we MUST do the _Retrieving_ - triples in the default graph 
according to the RDF 1.1 should still be in the default graph according to 
[org.apache.commons.rdf.api.Quad](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/api/Quad.html)
 - importantly it must be `.equals()` an equivalent quad statement in a 
different implementation. I think we all agree on this.  

Similarly _Parsing_ we MUST handle - at least when it's no longer 
experimental.

The question is how helpful we should be in the other cases. If someone is 
_adapting_ a Jena Quad, then I think it also MUST convert to `Optional.empty()` 
although it keeps the original Jena quad underneath, which can distinguish 
between the two default variants, if needed.

Now that leaves _creating_ which is a bit more speculative - we don't know 
where the graph `IRI` comes from, and other `RDF` implementations do of course 
not do anything special with `urn:x-arq:DefaultGraph`. However it is unlikely 
that such an IRI would be used in a non-Jena context. 

So here are three options for what `RDF.createQuad(g,s,p,o) should do if g 
is `urn:x-arq:DefaultGraph` or `urn:x-arq:DefaultGraphNode`:

1) Always recognize `urn:x-arq:DefaultGraph` and friends (either by 
comparing of IRI string against the `Quad.defaultGraph` and 
`Quad.defaultGraphNode` constants  (this PR), or adapting/unwrapping to the 
equivalent Jena `Node` and then checking with `Quad.isDefaultGraph(Node)`  
(might be less efficient)
2) Only recognize if it is a `org.apache.commons.rdf.jena.JenaIRI` instance 
by using `Quad.isDefaultGraph(iri.asJenaNode())`
3) Never recognize it, IRI will be left as-is. Insertion of such a `Quad` 
to a Jena-backed Dataset will then have different semantics then in other 
`Dataset`s

I think it's an edge-case with people creating it by hand from the IRI 
string with `RDF.createIRI()` - particularly with a non-Jena `RDF` instance, 
although that could be the case in queries against the union graph. (but that 
would only be in SPARQL world, right?).

However it might be conceivable that `Node` from `Quad.defaultGraph` is 
used in Jena-centric code that adds Commons RDF at the edge.


Boundaries from Commons RDF to Jena are simpler, as we just always use 
`urn:x-arq:DefaultGraph` (not `null`!) except where there's a pre-existing Jena 
`Quad` which is left as-is.


> Stream of Jena quads use wrong IRI for default graph
> 
>
> Key: COMMONSRDF-55
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-55
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: jena
>Affects Versions: 0.3.0
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
> Fix For: 1.0.0
>
>
> See https://travis-ci.org/apache/commons-rdf/builds/195548479
> {code}
> org.apache.commons.rdf.jena.DatasetJenaTest
> streamLanguageTagsCaseInsensitive(org.apache.commons.rdf.jena.DatasetJenaTest)
>   Time elapsed: 0.012 sec  <<< FAILURE!
> java.lang.AssertionError: expected:< 
>  "Hello"@EN-GB .> but 
> was:<

[jira] [Commented] (COMMONSRDF-55) Stream of Jena quads use wrong IRI for default graph

2017-02-02 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15849768#comment-15849768
 ] 

ASF GitHub Bot commented on COMMONSRDF-55:
--

Github user afs commented on the issue:

https://github.com/apache/commons-rdf/pull/32
  
`defaultGraph` is explicit name of the default graph in Jena, 
`defaultGraphNode` is for when the system is generating it, not for data.  
There are methods for "is this the default graph?" that abstract away from this 
detail. 

The mark in the graph slot of the quad is anything to distinguish it - Jena 
uses a URI although it is not properly "U"niversal - it is relative is the 
dataset. A quad is a triple from a graph in a dataset.  Triples are universal.

I guess I don't see the issue here: why is it not "Commons RDF marker for 
Quad/dft graph" <=> "System X marker for Quad/dft graph" at the adapter 
boundary.


> Stream of Jena quads use wrong IRI for default graph
> 
>
> Key: COMMONSRDF-55
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-55
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: jena
>Affects Versions: 0.3.0
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
> Fix For: 1.0.0
>
>
> See https://travis-ci.org/apache/commons-rdf/builds/195548479
> {code}
> org.apache.commons.rdf.jena.DatasetJenaTest
> streamLanguageTagsCaseInsensitive(org.apache.commons.rdf.jena.DatasetJenaTest)
>   Time elapsed: 0.012 sec  <<< FAILURE!
> java.lang.AssertionError: expected:< 
>  "Hello"@EN-GB .> but 
> was:<  "Hello"@en-GB .>
> {code}
> Jena uses the IRI `` internally to represent the 
> default graph within datasets - we need to recognize that on the way out of a 
> `JenaDatasetImpl.stream()` and possibly in the `asQuad(JenaQuad)` converter 
> and replace it with `Optional.empty()` so the default graph appears the same 
> across implementations.
> The `AbstractDatasetTest`  should be augmented to do more tests on the 
> default graph, including `.stream()`, `.iterate()`, `.contains()` and 
> `.remove()`1.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)