[jira] [Resolved] (COMMONSRDF-53) Add ServiceLoader support in OSGi

2017-01-11 Thread JIRA 

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

Sergio Fernández resolved COMMONSRDF-53.

Resolution: Fixed
  Assignee: Sergio Fernández

[PR #29|https://github.com/apache/commons-rdf/pull/29] merged in 
[3887517|https://github.com/apache/commons-rdf/commit/3887517a6f445c9944b9350abf98f0df9272d905].

> Add ServiceLoader support in OSGi
> -
>
> Key: COMMONSRDF-53
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-53
> Project: Apache Commons RDF
>  Issue Type: Improvement
>  Components: jena, jsonld-java, rdf4j, simple
>Affects Versions: 0.3.0
> Environment: OSGi
>Reporter: Aaron Coburn
>Assignee: Sergio Fernández
>  Labels: osgi
> Fix For: 1.0.0
>
>
> The ServiceLoader works differently in OSGi environments, such that it is 
> necessary to add bundle-level metadata defining which service interfaces are 
> provided by a particular OSGi bundle. This would improve OSGi support for 
> commons-rdf modules.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-53) Add ServiceLoader support in OSGi

2017-01-11 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on COMMONSRDF-53:
--

Github user asfgit closed the pull request at:

https://github.com/apache/commons-rdf/pull/29


> Add ServiceLoader support in OSGi
> -
>
> Key: COMMONSRDF-53
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-53
> Project: Apache Commons RDF
>  Issue Type: Improvement
>  Components: jena, jsonld-java, rdf4j, simple
>Affects Versions: 0.3.0
> Environment: OSGi
>Reporter: Aaron Coburn
>  Labels: osgi
> Fix For: 1.0.0
>
>
> The ServiceLoader works differently in OSGi environments, such that it is 
> necessary to add bundle-level metadata defining which service interfaces are 
> provided by a particular OSGi bundle. This would improve OSGi support for 
> commons-rdf modules.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-53) Add ServiceLoader support in OSGi

2017-01-11 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on COMMONSRDF-53:
--

GitHub user acoburn opened a pull request:

https://github.com/apache/commons-rdf/pull/29

[COMMONSRDF-53] Add ServiceLoader support in OSGi

Resolves: COMMONSRDF-53

This adds bundle metadata for the commons-rdf modules to make it easier to 
work with the Java `ServiceLoader` in an OSGi context. This consolidates the 
OSGi configuration, removing the `commons.osgi.symbolicName` definition and 
putting all OSGi-related configuration directly in the `maven-bundle-plugin` 
(now that the plugin must be explicitly configured in maven).

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

$ git pull https://github.com/acoburn/commons-rdf osgi_serviceloader

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

https://github.com/apache/commons-rdf/pull/29.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 #29


commit 27dbd9eda02550df85734c6198a0308cf5ca55e0
Author: Aaron Coburn 
Date:   2017-01-11T15:11:38Z

Add ServiceLoader support in OSGi




> Add ServiceLoader support in OSGi
> -
>
> Key: COMMONSRDF-53
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-53
> Project: Apache Commons RDF
>  Issue Type: Improvement
>  Components: jena, jsonld-java, rdf4j, simple
>Affects Versions: 0.3.0
> Environment: OSGi
>Reporter: Aaron Coburn
>  Labels: osgi
> Fix For: 1.0.0
>
>
> The ServiceLoader works differently in OSGi environments, such that it is 
> necessary to add bundle-level metadata defining which service interfaces are 
> provided by a particular OSGi bundle. This would improve OSGi support for 
> commons-rdf modules.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (COMMONSRDF-53) Add ServiceLoader support in OSGi

2017-01-11 Thread Aaron Coburn (JIRA) 
Aaron Coburn created COMMONSRDF-53:
--

 Summary: Add ServiceLoader support in OSGi
 Key: COMMONSRDF-53
 URL: https://issues.apache.org/jira/browse/COMMONSRDF-53
 Project: Apache Commons RDF
  Issue Type: Improvement
  Components: jena, jsonld-java, rdf4j, simple
Affects Versions: 0.3.0
 Environment: OSGi
Reporter: Aaron Coburn
 Fix For: 1.0.0


The ServiceLoader works differently in OSGi environments, such that it is 
necessary to add bundle-level metadata defining which service interfaces are 
provided by a particular OSGi bundle. This would improve OSGi support for 
commons-rdf modules.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

2017-01-11 Thread Andy Seaborne (JIRA) 

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

Andy Seaborne commented on COMMONSRDF-51:
-

Languages tags in BCP 47 says "ALPHA" which is defined in RFC5234 as "A-Z, a-z".


> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (BCEL-276) LocalVariableTypeTable is not updated.

2017-01-11 Thread Mark Roberts (JIRA) 

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

Mark Roberts updated BCEL-276:
--
Attachment: MethodGen.mark.diff
LocalVariableGen.mark.diff
LocalVariable.mark.diff

> LocalVariableTypeTable is not updated. 
> ---
>
> Key: BCEL-276
> URL: https://issues.apache.org/jira/browse/BCEL-276
> Project: Commons BCEL
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Sam Yoon
>Assignee: Benedikt Ritter
>  Labels: github
> Fix For: 6.1
>
> Attachments: LocalVariable.mark.diff, LocalVariableGen.mark.diff, 
> LocalVariableTypeTableTest.java, MethodGen.diff, MethodGen.mark.diff, 
> SimpleClassHasMethodIncludeGenericArgument.java
>
>
> If a method for BCI have at least one generic type of argument JVM throw 
> java.lang.ClassFormatError due to not updated LocalVariableTable.
> I know there is workaround as call removeLocalVariables method.
> But I think it's better that BCEL can stay proper LocalVariableTable.
> I'm also pull test case can reproduce error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (BCEL-276) LocalVariableTypeTable is not updated.

2017-01-11 Thread Mark Roberts (JIRA) 

[ 
https://issues.apache.org/jira/browse/BCEL-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15818938#comment-15818938
 ] 

Mark Roberts commented on BCEL-276:
---

I was able to get the code working to pass both your tests and my tests, but 
there were two issues that needed to be fixed. First, when copying the 
LocalVariableTypeTable, you need to make a true copy, not just save the 
pointer. Approx line 229. The other change is more complex. You cannot match a 
LocalVariable and a LocalVariableType based on having the same index and it may 
have been modified. I Added code to LocalVariable.java and 
LocalVariableGen.java to maintain a copy of the original index of a 
LocalVariable and then use this for matching.

I have attached three diff files with my changes.

> LocalVariableTypeTable is not updated. 
> ---
>
> Key: BCEL-276
> URL: https://issues.apache.org/jira/browse/BCEL-276
> Project: Commons BCEL
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Sam Yoon
>Assignee: Benedikt Ritter
>  Labels: github
> Fix For: 6.1
>
> Attachments: LocalVariableTypeTableTest.java, MethodGen.diff, 
> SimpleClassHasMethodIncludeGenericArgument.java
>
>
> If a method for BCI have at least one generic type of argument JVM throw 
> java.lang.ClassFormatError due to not updated LocalVariableTable.
> I know there is workaround as call removeLocalVariables method.
> But I think it's better that BCEL can stay proper LocalVariableTable.
> I'm also pull test case can reproduce error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

2017-01-11 Thread Stian Soiland-Reyes (JIRA) 

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

Stian Soiland-Reyes edited comment on COMMONSRDF-51 at 1/11/17 4:24 PM:


I think this needs to be clarified on public-rdf-comme...@w3.org as our 
"character by character" is a [quote from the 
spec|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal]:

{quote}

Literal term equality: Two literals are term-equal (the same RDF literal) if 
and only if the two lexical forms, the two datatype IRIs, and the two language 
tags (if any) compare equal, character by character. Thus, two literals can 
have the same value without being the same RDF term. For example:

  "1"^^xs:integer
  "01"^^xs:integer

denote the same value, but are not the same literal RDF terms and are not 
term-equal because their lexical form differs.
{quote}

It also says above the value space is always in lower case, but then says 
equality is done "character by character" -- not by value space.  (As that 
example shows, the lexical value of data types like integers are also compared 
by character instead of by value space)

I have nevertheless started a branch 
[COMMONSRDF-51-langtag-lcase|https://github.com/apache/commons-rdf/compare/COMMONSRDF-51-langtag-lcase]
 to try this out.. this revealed bugs in the bindings for simple (just the 
Turkish case), jsonld-java (which does no validation of language tags), rdf4j 
(fails Turkish test) and jena (fails Turkish test).

As both RDF4J and Jena are vulnerable to the Turkish case, that should be 
reported upstream after rdf-comments clarifications.

Would it make sense for Commons RDF to strengthen getLanguageTag() to ALWAYS 
return the language tag in lower case for any RDF implementations (e.g. 
normalize if implementation does not do it correctly internally) - as a kind of 
interoperability/RDF 1.1 measure - or should we strive to keep their current 
case representation as-is? 


was (Author: stain):
I think this needs to be clarified on public-rdf-comme...@w3.org as our 
"character by character" is a [quote from the 
spec|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal]:

{quote}

Literal term equality: Two literals are term-equal (the same RDF literal) if 
and only if the two lexical forms, the two datatype IRIs, and the two language 
tags (if any) compare equal, character by character. Thus, two literals can 
have the same value without being the same RDF term. For example:

  "1"^^xs:integer
  "01"^^xs:integer

denote the same value, but are not the same literal RDF terms and are not 
term-equal because their lexical form differs.
{quote}

It also says above the value space is always in lower case, but then says 
equality is done "character by character" and not by value space.  (As that 
example shows, the lexical value of data types like integers are also compared 
by character instead of by value space)

I have nevertheless started a branch 
[COMMONSRDF-51-langtag-lcase|https://github.com/apache/commons-rdf/compare/COMMONSRDF-51-langtag-lcase]
 to try this out.. this revealed bugs in the bindings for simple (just the 
Turkish case), jsonld-java (which does no validation of language tags), rdf4j 
(fails Turkish test) and jena (fails Turkish test).

As both RDF4J and Jena are vulnerable to the Turkish case, that should be 
reported upstream after rdf-comments clarifications.

Would it make sense for Commons RDF to strengthen getLanguageTag() to ALWAYS 
return the language tag in lower case for any RDF implementations (e.g. 
normalize if implementation does not do it correctly internally) - as a kind of 
interoperability/RDF 1.1 measure - or should we strive to keep their current 
case representation as-is? 

> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done

[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

2017-01-11 Thread Stian Soiland-Reyes (JIRA) 

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

Stian Soiland-Reyes commented on COMMONSRDF-51:
---

TODO: Stian to report to public-rdf-comments@w3

> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

2017-01-11 Thread Stian Soiland-Reyes (JIRA) 

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

Stian Soiland-Reyes commented on COMMONSRDF-51:
---

I think this needs to be clarified on public-rdf-comme...@w3.org as our 
"character by character" is a [quote from the 
spec|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal]:

{quote}

Literal term equality: Two literals are term-equal (the same RDF literal) if 
and only if the two lexical forms, the two datatype IRIs, and the two language 
tags (if any) compare equal, character by character. Thus, two literals can 
have the same value without being the same RDF term. For example:

  "1"^^xs:integer
  "01"^^xs:integer

denote the same value, but are not the same literal RDF terms and are not 
term-equal because their lexical form differs.
{quote}

It also says above the value space is always in lower case, but then says 
equality is done "character by character" and not by value space.  (As that 
example shows, the lexical value of data types like integers are also compared 
by character instead of by value space)

I have nevertheless started a branch 
[COMMONSRDF-51-langtag-lcase|https://github.com/apache/commons-rdf/compare/COMMONSRDF-51-langtag-lcase]
 to try this out.. this revealed bugs in the bindings for simple (just the 
Turkish case), jsonld-java (which does no validation of language tags), rdf4j 
(fails Turkish test) and jena (fails Turkish test).

As both RDF4J and Jena are vulnerable to the Turkish case, that should be 
reported upstream after rdf-comments clarifications.

Would it make sense for Commons RDF to strengthen getLanguageTag() to ALWAYS 
return the language tag in lower case for any RDF implementations (e.g. 
normalize if implementation does not do it correctly internally) - as a kind of 
interoperability/RDF 1.1 measure - or should we strive to keep their current 
case representation as-is? 

> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-52) Duplicate Bundle-SymbolicName values across all components

2017-01-11 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on COMMONSRDF-52:
--

Github user acoburn commented on the issue:

https://github.com/apache/commons-rdf/pull/28
  
@stain for a `ServiceLoader` equivalent in OSGi, it would make sense to add 
a `Require-Capability` and `Provide-Capability` to each implementation's 
`MANIFEST.MF` -- it will simply be some minor maven changes, and I can add that 
in a forthcoming pull request.


> Duplicate Bundle-SymbolicName values across all components
> --
>
> Key: COMMONSRDF-52
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-52
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api, jena, jsonld-java, rdf4j, simple
>Affects Versions: 0.3.0
> Environment: OSGi provisioning
>Reporter: Aaron Coburn
>Assignee: Stian Soiland-Reyes
> Fix For: 1.0.0
>
>
> In the 0.3.0-incubating release, all of the commons-rdf bundles have the same 
> Symbolic-BundleName, namely: org.apache.commons.rdf. This makes it impossible 
> to install multiple bundles in an OSGi container (e.g. Karaf), as every 
> bundle must have a distinct Symbolic-BundleName/Version combination.
> The commons-parent pom configuration provides a mechanism for setting the 
> value of Symbolic-BundleName in the bundle manifest by overriding the 
> property value for commons.osgi.symbolicName.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

2017-01-11 Thread Stian Soiland-Reyes (JIRA) 

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

Stian Soiland-Reyes updated COMMONSRDF-51:
--
Description: 
The [RDF-1.1 specification states that the [value space of Literal language 
tags is lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], 
which does not conflict with the case-insensitive specification in BCP47. The 
Literal.equals and Literal.hashCode API contracts should specify that language 
tags must be compared using lowercase, even if they are otherwise stored and 
returned as upper-case by getLanguageTag. The API currently has incorrect 
language by saying "character-by-character" for language tag comparisons, as 
that implies case-sensitive comparisons are used.

The lowercasing must also be done using a locale that is consistent (known 
example where lowercase and uppercase do not roundtrip as expected for US-ASCII 
characters is Turkish [1]), so I would recommend actually stating that 
.toLowerCase(Locale.ENGLISH) is used.

  was:
The RDF-1.1 specification states that the value space of Literal language tags 
is lowercase, which does not conflict with the case-insensitive specification 
in BCP47. The Literal.equals and Literal.hashCode API contracts should specify 
that language tags must be compared using lowercase, even if they are otherwise 
stored and returned as upper-case by getLanguageTag. The API currently has 
incorrect language by saying "character-by-character" for language tag 
comparisons, as that implies case-sensitive comparisons are used.

The lowercasing must also be done using a locale that is consistent (known 
example where lowercase and uppercase do not roundtrip as expected for US-ASCII 
characters is Turkish [1]), so I would recommend actually stating that 
.toLowerCase(Locale.ENGLISH) is used.


> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (COMMONSRDF-52) Duplicate Bundle-SymbolicName values across all components

2017-01-11 Thread Stian Soiland-Reyes (JIRA) 

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

Stian Soiland-Reyes resolved COMMONSRDF-52.
---
Resolution: Fixed
  Assignee: Stian Soiland-Reyes

Merged https://github.com/apache/commons-rdf/pull/28 from Aaron Coburn.

> Duplicate Bundle-SymbolicName values across all components
> --
>
> Key: COMMONSRDF-52
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-52
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api, jena, jsonld-java, rdf4j, simple
>Affects Versions: 0.3.0
> Environment: OSGi provisioning
>Reporter: Aaron Coburn
>Assignee: Stian Soiland-Reyes
> Fix For: 1.0.0
>
>
> In the 0.3.0-incubating release, all of the commons-rdf bundles have the same 
> Symbolic-BundleName, namely: org.apache.commons.rdf. This makes it impossible 
> to install multiple bundles in an OSGi container (e.g. Karaf), as every 
> bundle must have a distinct Symbolic-BundleName/Version combination.
> The commons-parent pom configuration provides a mechanism for setting the 
> value of Symbolic-BundleName in the bundle manifest by overriding the 
> property value for commons.osgi.symbolicName.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-52) Duplicate Bundle-SymbolicName values across all components

2017-01-11 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on COMMONSRDF-52:
--

Github user stain commented on the issue:

https://github.com/apache/commons-rdf/pull/28
  
Thanks! Merged. I also added you as a `` to be shown on 
https://commons.apache.org/proper/commons-rdf/team-list.html - hope that's OK.

Any other OSGi issues? How do you do the equivalent of `ServiceLoader` of 
`RDF` instances? Do we need to make OSGi service annotations/XML?


> Duplicate Bundle-SymbolicName values across all components
> --
>
> Key: COMMONSRDF-52
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-52
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api, jena, jsonld-java, rdf4j, simple
>Affects Versions: 0.3.0
> Environment: OSGi provisioning
>Reporter: Aaron Coburn
> Fix For: 1.0.0
>
>
> In the 0.3.0-incubating release, all of the commons-rdf bundles have the same 
> Symbolic-BundleName, namely: org.apache.commons.rdf. This makes it impossible 
> to install multiple bundles in an OSGi container (e.g. Karaf), as every 
> bundle must have a distinct Symbolic-BundleName/Version combination.
> The commons-parent pom configuration provides a mechanism for setting the 
> value of Symbolic-BundleName in the bundle manifest by overriding the 
> property value for commons.osgi.symbolicName.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-52) Duplicate Bundle-SymbolicName values across all components

2017-01-11 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on COMMONSRDF-52:
--

Github user asfgit closed the pull request at:

https://github.com/apache/commons-rdf/pull/28


> Duplicate Bundle-SymbolicName values across all components
> --
>
> Key: COMMONSRDF-52
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-52
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api, jena, jsonld-java, rdf4j, simple
>Affects Versions: 0.3.0
> Environment: OSGi provisioning
>Reporter: Aaron Coburn
> Fix For: 1.0.0
>
>
> In the 0.3.0-incubating release, all of the commons-rdf bundles have the same 
> Symbolic-BundleName, namely: org.apache.commons.rdf. This makes it impossible 
> to install multiple bundles in an OSGi container (e.g. Karaf), as every 
> bundle must have a distinct Symbolic-BundleName/Version combination.
> The commons-parent pom configuration provides a mechanism for setting the 
> value of Symbolic-BundleName in the bundle manifest by overriding the 
> property value for commons.osgi.symbolicName.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TEXT-58) All uppercase methods?

2017-01-11 Thread Gilles (JIRA) 
Gilles created TEXT-58:
--

 Summary: All uppercase methods?
 Key: TEXT-58
 URL: https://issues.apache.org/jira/browse/TEXT-58
 Project: Commons Text
  Issue Type: Improvement
Reporter: Gilles
Priority: Trivial
 Fix For: 1.0


Class {{o.a.c.text.translate.JavaUnicodeEscaper}} contains methods names with 
all uppercase letters (and underscores).

I understand that they create copies of _static_ constants (although even that 
is not true since they return arrays!), but are you sure you want to release a 
new component that does not follow the usual convention?

I understand these comes from LANG but isn't it the right time to fix the API?




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)