[jira] [Commented] (TEXT-59) Mutable static data
[
https://issues.apache.org/jira/browse/TEXT-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833254#comment-15833254
]
Rob Tompkins commented on TEXT-59:
--
All of the work on this issue is being tracked in TEXT-58.
> Mutable static data
> ---
>
> Key: TEXT-59
> URL: https://issues.apache.org/jira/browse/TEXT-59
> Project: Commons Text
> Issue Type: Bug
>Reporter: Gilles
>Assignee: Rob Tompkins
> Fix For: 1.0
>
>
> Class {{o.a.c.text.translate.EntityArrays}} contain methods that return
> mutable data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (VFS-629) Update Apache Commons Compress from 1.12 to 1.13.
Gary Gregory created VFS-629: Summary: Update Apache Commons Compress from 1.12 to 1.13. Key: VFS-629 URL: https://issues.apache.org/jira/browse/VFS-629 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.1 Reporter: Gary Gregory Assignee: Gary Gregory Update Apache Commons Compress from 1.12 to 1.13. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (VFS-628) Add a file inverter FileSelector: InvertIncludeFileSelector
[
https://issues.apache.org/jira/browse/VFS-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-628.
Resolution: Fixed
Fix Version/s: 2.2
In svn trunk.
> Add a file inverter FileSelector: InvertIncludeFileSelector
> ---
>
> Key: VFS-628
> URL: https://issues.apache.org/jira/browse/VFS-628
> Project: Commons VFS
> Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.2
>
>
> Add a FileSelector implementation that inverts the result of a delegate
> FileSelector's includeFile method. Tree traversal is unchanged. Proposed
> class name: {{InvertIncludeFileSelector}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (VFS-628) Add a file inverter FileSelector: InvertIncludeFileSelector
Gary Gregory created VFS-628:
Summary: Add a file inverter FileSelector:
InvertIncludeFileSelector
Key: VFS-628
URL: https://issues.apache.org/jira/browse/VFS-628
Project: Commons VFS
Issue Type: Improvement
Reporter: Gary Gregory
Assignee: Gary Gregory
Add a FileSelector implementation that inverts the result of a delegate
FileSelector's includeFile method. Tree traversal is unchanged. Proposed class
name: {{InvertIncludeFileSelector}}.
--
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=15833155#comment-15833155 ] ASF GitHub Bot commented on COMMONSRDF-51: -- Github user afs commented on the issue: https://github.com/apache/commons-rdf/pull/30 RDF 1.1 mentions: 1. Turtle parsing - there is a lang tag rule. 2. The text that conversion to a lowercase lexical is allowed. 3. Value-comparison is case insensitive. Which is that test for? Lexical or value? At least acknowledging that RDF's "lowercase" is not in keeping with BCP 47 syntax canonicalization (the registry may change the characters) whatever the spec makes sense to me and I suspect domain experts; it's following the spec that "owns" language tags. Focus on the value comparison. > 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] [Resolved] (CONFIGURATION-649) XMLConfiguration changes list format on saving
[
https://issues.apache.org/jira/browse/CONFIGURATION-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-649.
Resolution: Fixed
Fix Version/s: 2.2
A fix has been implemented which improves the list handling of
XMLConfiguration. In many constellations lists defined as single string with
delimiter characters now retain their original format when the configuration is
saved.
The solution is not perfect, however. For instance, for list properties using a
mixed format (multiple XML elements each of which defining multiple list items)
the format is lost. Also if a list property is fully removed and later added
again.
> XMLConfiguration changes list format on saving
> --
>
> Key: CONFIGURATION-649
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-649
> Project: Commons Configuration
> Issue Type: Bug
> Components: Format
>Affects Versions: 2.1
>Reporter: Oliver Heger
> Fix For: 2.2
>
>
> If the XML document loaded by the configuration contains a string property
> with multiple values (separated by the list delimiter character), on saving,
> this property is split into multiple nodes. So
> {noformat}
> a,b,c
> {noformat}
> becomes
> {noformat}
> a
> b
> c
> {noformat}
> This also happens if the property is not touched before saving. The reason
> for this behavior is that on loading new nodes are created for the single
> list items (which is required to have an internal model on which queries can
> be executed). On saving, these nodes are considered new nodes, and thus new
> XML elements are created for them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (NUMBERS-3) Make "RootsOfUnity" immutable
[
https://issues.apache.org/jira/browse/NUMBERS-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved NUMBERS-3.
--
Resolution: Fixed
commit b206d9c80c95433d530e639308e38b92c7e3fdef
> Make "RootsOfUnity" immutable
> -
>
> Key: NUMBERS-3
> URL: https://issues.apache.org/jira/browse/NUMBERS-3
> Project: Commons Numbers
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Labels: api, immutable, serialization
>
> The computation could be performed in the constructor, allowing
> all fields to be made "final".
> Synchronized methods would become unnecessary to ensure thread-safety, and
> numerous checks (to guard against a non-initialized instance) could be
> dropped.
> Overall the code can be simplified at the cost of dropping the "clockwise"
> store (see current version).
> An accessor method to get the each of the roots as a {{Complex}} should be
> provided, to replace the current separate retrieval of its real and imaginary
> parts.
> Also this class should not be {{Serializable}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (NUMBERS-4) Complex.ZERO.pow(2.0) is NaN
[
https://issues.apache.org/jira/browse/NUMBERS-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved NUMBERS-4.
--
Resolution: Fixed
commit 2b29ed84c9461fba037b8ebfd8a39637c08b6b3e
> Complex.ZERO.pow(2.0) is NaN
>
>
> Key: NUMBERS-4
> URL: https://issues.apache.org/jira/browse/NUMBERS-4
> Project: Commons Numbers
> Issue Type: Bug
> Environment: Linux, Java1.7/Java1.8
>Reporter: Raymond DeCampo
>Priority: Minor
>
> Description copied from MATH-1397 as reported by Mario Wenzel:
> {quote}
> ```
> package complextest;
> import org.apache.commons.math3.complex.Complex;
> public class T \{
> public static void main(String[] args)
> \{ System.out.println(Complex.ZERO.pow(2.0)); }
> }
> ```
> This is the code and the readout is `(NaN, NaN)`. This surely isn't right.
> For one, it should actually be zero
> (https://www.wolframalpha.com/input/?i=(0%2B0i)%5E2) and second of all, the
> documentation doesn't state that anything could go wrong from a Complex
> number that has no NaNs and Infs.
> The other definition states that it doesn't work when the base is Zero, but
> it surely should. This strange corner case destroys any naive implementation
> of stuff wrt the mandelbrot set.
> It would be nice to not have to implement this exception myself.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TEXT-58) All uppercase methods?
[
https://issues.apache.org/jira/browse/TEXT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833038#comment-15833038
]
Rob Tompkins commented on TEXT-58:
--
I've found an interesting curiosity here. Bruno suggested that we simply use
the newly created UnmodifyableMaps to populate the {{lookupMap}} in the
{{LookupTranslator}}. Unfortunately, to be sufficiently general in the
constructor, we would probably wish that it consume a {{Map}}. This causes issues in that the translate method only works on
{{CharSequences}} that have an implemented {{equals}} and {{hashCode}}. We
thus, if we wish to remain sufficiently general in the constructor, still need
to build up a new {{Map}} from the input {{Map}}.
I think we should still do this, but I wanted to bring the point up while I'm
in here doing the work. Furthermore, we need to consider
https://issues.apache.org/jira/browse/LANG-882 as a reference about why we need
do this.
> 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] (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=15832938#comment-15832938 ] Don Jeba commented on TEXT-45: -- Is this issue still valid? The reason I am asking is, the class WordUtils is not found under https://github.com/apache/commons-text OR i am missing something? Kindly clarify, thank you! > 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] [Comment Edited] (LANG-1295) ArrayUtils.toArray(T... items) has unsafe use of varargs
[
https://issues.apache.org/jira/browse/LANG-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15832097#comment-15832097
]
Pascal Schumacher edited comment on LANG-1295 at 1/21/17 10:51 AM:
---
As I first step I have just removed the SafeVarargs annotation from the method.
was (Author: pascalschumacher):
As I first step I just removed the SafeVarargs annotation from the method.
> ArrayUtils.toArray(T... items) has unsafe use of varargs
>
>
> Key: LANG-1295
> URL: https://issues.apache.org/jira/browse/LANG-1295
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Critical
>
> {{ArrayUtils.toArray(T... items)}} is marked as {{@SafeVarargs}}, but I
> suspect the use of the varargs is unsafe.
> An example, drawn heavily from [this StackOverflow
> answer|http://stackoverflow.com/a/14252221/474189], demonstrates this:
> {code:java}
> static T[] arrayOfTwo(T a, T b) {
> return ArrayUtils.toArray(a, b);
> }
> @Test
> public void testBadVarArgs() throws Exception {
> @SuppressWarnings("unused") // Need to assign to trigger exception
> String[] result = arrayOfTwo("foo", "bar");
> }
> {code}
> the above code throws an exception: {{java.lang.ClassCastException:
> [Ljava.lang.Object; cannot be cast to [Ljava.lang.String;}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (NUMBERS-8) Jenkins setup
[ https://issues.apache.org/jira/browse/NUMBERS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved NUMBERS-8. -- Resolution: Done https://builds.apache.org/view/Apache%20Commons/job/Commons_Numbers/ > Jenkins setup > - > > Key: NUMBERS-8 > URL: https://issues.apache.org/jira/browse/NUMBERS-8 > Project: Commons Numbers > Issue Type: Task >Reporter: Gilles > Labels: Jenkins > Fix For: 1.0 > > > Create a [Jenkins|https://builds.apache.org/view/Apache%20Commons/] > continuous integration task. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JEXL-220) Release 3.1 to Maven Repository
[ https://issues.apache.org/jira/browse/JEXL-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15832877#comment-15832877 ] Dmitri Blinov commented on JEXL-220: I can confirm that on my site the current build works without any known issues so I think it is ready for release. Though it would be nice before to fix JEXL-211 since its only one line of the code and does not break any interfaces. My 2p. > Release 3.1 to Maven Repository > --- > > Key: JEXL-220 > URL: https://issues.apache.org/jira/browse/JEXL-220 > Project: Commons JEXL > Issue Type: Wish >Affects Versions: 3.1 >Reporter: Doug Whitehead >Priority: Minor > > Any chance version 3.1 is scheduled for a release to the Maven Repository any > time soon? Seems like there are plenty of improvements and bug fixes to > warrant a release, and also -- last release was a year go at this point :) > https://mvnrepository.com/artifact/org.apache.commons/commons-jexl3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang issue #228: Increase test coverage
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/228 [](https://coveralls.io/builds/9779557) Coverage increased (+0.07%) to 94.529% when pulling **00bf35cdd92813881274a355a33e7e659f5eddaa on andyklimczak:test-coverage** into **86a082e8be8c51f07079ded82d6d125c9efc1791 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 #228: Increase test coverage
GitHub user andyklimczak opened a pull request: https://github.com/apache/commons-lang/pull/228 Increase test coverage CharRangeTest 98% -> 100% RandomUtilsTest 90% -> 100% StringEscapeUtilsTest 95% -> 100% StringUtilsTest -> 99% (a few more lines covered) You can merge this pull request into a Git repository by running: $ git pull https://github.com/andyklimczak/commons-lang test-coverage Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/228.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 #228 commit 00bf35cdd92813881274a355a33e7e659f5eddaa Author: Andy Klimczak Date: 2017-01-21T07:50:50Z Increase test coverage CharRangeTest -> 100% RandomUtilsTest -> 100% StringEscapeUtilsTest -> 100% StringUtils -> 99% --- 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. ---
