[jira] [Commented] (TEXT-60) Build failures when building with Java 9 EA
[
https://issues.apache.org/jira/browse/TEXT-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15834490#comment-15834490
]
Rob Tompkins commented on TEXT-60:
--
Furthermore, upgrading from {{0.7.7.201606060606}} to {{0.7.8}} by adding
{{0.7.8}} to the pom.xml works.
> Build failures when building with Java 9 EA
> ---
>
> Key: TEXT-60
> URL: https://issues.apache.org/jira/browse/TEXT-60
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Rob Tompkins
>
> When I run {{mvn clean test}} with maven 3.3.9, and java build 9-ea+153, I
> get the following:
> {code}
> CompositeFormatTest.testUsage:77 » ServiceConfiguration
> sun.util.locale.provid...
> ExtendedMessageFormatTest.testBuiltInChoiceFormat:207 »
> ServiceConfiguration s...
> ExtendedMessageFormatTest.testBuiltInDateTimeFormat:225 »
> ServiceConfiguration
> ExtendedMessageFormatTest.testBuiltInNumberFormat:276 »
> ServiceConfiguration s...
> ExtendedMessageFormatTest.testEmbeddedPatternInChoice:81 »
> ServiceConfiguration
> ExtendedMessageFormatTest.testExtendedAndBuiltInFormats:106 »
> ServiceConfiguration
> ExtendedMessageFormatTest.testOverriddenBuiltinFormat:246 »
> ServiceConfiguration
> StrBuilderAppendInsertTest.testAppend_FormattedString:1048 »
> ServiceConfiguration
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TEXT-60) Build failures when building with Java 9 EA
[
https://issues.apache.org/jira/browse/TEXT-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15834484#comment-15834484
]
Rob Tompkins commented on TEXT-60:
--
{{mvn -Djacoco.skip clean test}} seems to resolve this issue.
> Build failures when building with Java 9 EA
> ---
>
> Key: TEXT-60
> URL: https://issues.apache.org/jira/browse/TEXT-60
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Rob Tompkins
>
> When I run {{mvn clean test}} with maven 3.3.9, and java build 9-ea+153, I
> get the following:
> {code}
> CompositeFormatTest.testUsage:77 » ServiceConfiguration
> sun.util.locale.provid...
> ExtendedMessageFormatTest.testBuiltInChoiceFormat:207 »
> ServiceConfiguration s...
> ExtendedMessageFormatTest.testBuiltInDateTimeFormat:225 »
> ServiceConfiguration
> ExtendedMessageFormatTest.testBuiltInNumberFormat:276 »
> ServiceConfiguration s...
> ExtendedMessageFormatTest.testEmbeddedPatternInChoice:81 »
> ServiceConfiguration
> ExtendedMessageFormatTest.testExtendedAndBuiltInFormats:106 »
> ServiceConfiguration
> ExtendedMessageFormatTest.testOverriddenBuiltinFormat:246 »
> ServiceConfiguration
> StrBuilderAppendInsertTest.testAppend_FormattedString:1048 »
> ServiceConfiguration
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TEXT-60) Build failures when building with Java 9 EA
Rob Tompkins created TEXT-60:
Summary: Build failures when building with Java 9 EA
Key: TEXT-60
URL: https://issues.apache.org/jira/browse/TEXT-60
Project: Commons Text
Issue Type: Bug
Affects Versions: 1.0
Reporter: Rob Tompkins
When I run {{mvn clean test}} with maven 3.3.9, and java build 9-ea+153, I get
the following:
{code}
CompositeFormatTest.testUsage:77 » ServiceConfiguration
sun.util.locale.provid...
ExtendedMessageFormatTest.testBuiltInChoiceFormat:207 » ServiceConfiguration
s...
ExtendedMessageFormatTest.testBuiltInDateTimeFormat:225 » ServiceConfiguration
ExtendedMessageFormatTest.testBuiltInNumberFormat:276 » ServiceConfiguration
s...
ExtendedMessageFormatTest.testEmbeddedPatternInChoice:81 »
ServiceConfiguration
ExtendedMessageFormatTest.testExtendedAndBuiltInFormats:106 »
ServiceConfiguration
ExtendedMessageFormatTest.testOverriddenBuiltinFormat:246 »
ServiceConfiguration
StrBuilderAppendInsertTest.testAppend_FormattedString:1048 »
ServiceConfiguration
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TEXT-45) WordUtils delimiters should be strings, not char varargs
[
https://issues.apache.org/jira/browse/TEXT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15834392#comment-15834392
]
Rob Tompkins commented on TEXT-45:
--
I agree with Pascal here. I believe that WordUtils is out on a branch named
{{TEXT-55}}. I will get it back in as soon as we get 1.0 out the door, which I
am attempting over the next week.
> WordUtils delimiters should be strings, not char varargs
>
>
> Key: TEXT-45
> URL: https://issues.apache.org/jira/browse/TEXT-45
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Andrew Pennebaker
>Priority: Minor
> Labels: api,, interface,ease,of,use,, robustness,
> Fix For: 1.1
>
>
> Strings behave like char varargs of arbitrary length, but are much easier to
> use.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TEXT-58) All uppercase methods?
[
https://issues.apache.org/jira/browse/TEXT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins resolved TEXT-58.
--
Resolution: Implemented
Pull request merged.
> All uppercase methods?
> --
>
> Key: TEXT-58
> URL: https://issues.apache.org/jira/browse/TEXT-58
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Rob Tompkins
>Priority: Trivial
> Labels: api, convention, standard
> Fix For: 1.0
>
>
> Class {{o.a.c.text.translate.EntityArrays}} 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)
[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case
[ https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15834333#comment-15834333 ] ASF GitHub Bot commented on COMMONSRDF-51: -- Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/30 I added equivalent tests for `Graph` add/contains/remove, and this fails for Jena: ``` java.lang.AssertionError at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertFalse(Assert.java:64) at org.junit.Assert.assertFalse(Assert.java:74) at org.apache.commons.rdf.api.AbstractGraphTest.containsLanguageTagsCaseInsensitive(AbstractGraphTest.java:415) ... ``` basically if I add `"Hello"@EN-GB` to a Jena Graph and then try to remove `"Hello"@en-GB` then the statement remains in the graph as `"Hello"@EN-GB`. How can we fix this? It would not be enough to just lowercase in all Commons RDF methods with Jena Literal language tags, as the Jena graph/model could be populated through other means (e.g. parsing a file). > 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] [Created] (NUMBERS-10) Revamp "Complex" representation ?
Gilles created NUMBERS-10:
-
Summary: Revamp "Complex" representation ?
Key: NUMBERS-10
URL: https://issues.apache.org/jira/browse/NUMBERS-10
Project: Commons Numbers
Issue Type: Wish
Reporter: Gilles
Fix For: 1.0
Attachments: CartesianRepresentation.java, Complex.java,
MixedRepresentation.java, PolarRepresentation.java
This is a proposal to enhance the internal representation of complex numbers.
The purpose is to allow usage of both cartesian and polar representations, with
the aim that calculations are performed (transparently) with the one that will
be more accurate and/or faster.
The API would certainly be improved, from
{code}
final Complex c1 = Complex.valueOf(1, 2);
final Complex c2 = ComplexUtils.polar2Complex(2, 7);
final Complex r = c1.add(c2);
{code}
with the current code, to
{code}
final Complex c1 = Complex.createCartesian(1, 2);
final Complex c2 = Complex.createPolar(2, 7);
final Complex r = c1.add(c2);
{code}
Please refer to the attached files (they are self-documenting, but of course,
Javadoc must be added if the proposal is validated).
Would there be merit in pursuing in that direction?
Or is there any show-stopper?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
