[jira] [Commented] (CODEC-236) Add MurmurHash Implementation

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047202#comment-16047202
 ] 

Gary Gregory commented on CODEC-236:


Feel free to provide a patch with unit tests :-) I would make sure the class is 
named appropriately since Wikipedia notes there is a MurmurHash2 and 
MurmurHash3.

> Add MurmurHash Implementation
> -
>
> Key: CODEC-236
> URL: https://issues.apache.org/jira/browse/CODEC-236
> Project: Commons Codec
>  Issue Type: New Feature
>Affects Versions: 1.10
>Reporter: BELUGA BEHR
>Priority: Minor
>
> https://en.wikipedia.org/wiki/MurmurHash
> Already exists an Apache implementation:
> org.apache.hive.common.util.HashCodeUtil.murmurHash(byte[], int, int)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[Arun Vinud (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047195#comment-16047195
 ] 

Arun Vinud  commented on TEXT-88:
-

What if I don't like to pass an explicit null as input and pass an empty 
delimiter array as input instead ? I would expect the same output as passing a 
null since "I have not provided any delimiters" but the current implementation 
gives a different output . I do agree that space is the most common delimiter 
and we should definitely provide support for that but my thinking is can we 
provide support to that in a more straight forward way ? As a consumer I feel I 
shouldn't have any surprise imho .

> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty 
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that 
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have 
> been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CODEC-236) Add MurmurHash Implementation

[BELUGA BEHR (JIRA)]

BELUGA BEHR created CODEC-236:
-

 Summary: Add MurmurHash Implementation
 Key: CODEC-236
 URL: https://issues.apache.org/jira/browse/CODEC-236
 Project: Commons Codec
  Issue Type: New Feature
Affects Versions: 1.10
Reporter: BELUGA BEHR
Priority: Minor


https://en.wikipedia.org/wiki/MurmurHash

Already exists an Apache implementation:

org.apache.hive.common.util.HashCodeUtil.murmurHash(byte[], int, int)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047099#comment-16047099
 ] 

ASF GitHub Bot commented on CLI-274:


Github user coveralls commented on the issue:

https://github.com/apache/commons-cli/pull/12
  

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

Coverage increased (+0.009%) to 96.244% when pulling 
**4f9c95bcb246b64f7f6756cc3840d2061a262fe7 on schaumb:patch-1** into 
**70a392756c713f404fed0e3ddd48aa18ce20485f on apache:master**.



> Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
>  Issue Type: Bug
>  Components: Parser
>Reporter: Béla Schaum
>Priority: Minor
>
> When the user pass option type FileInputStream.class, I think the expected 
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); // 
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047100#comment-16047100
 ] 

ASF GitHub Bot commented on CLI-274:


Github user coveralls commented on the issue:

https://github.com/apache/commons-cli/pull/12
  

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

Coverage increased (+0.009%) to 96.244% when pulling 
**4f9c95bcb246b64f7f6756cc3840d2061a262fe7 on schaumb:patch-1** into 
**70a392756c713f404fed0e3ddd48aa18ce20485f on apache:master**.



> Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
>  Issue Type: Bug
>  Components: Parser
>Reporter: Béla Schaum
>Priority: Minor
>
> When the user pass option type FileInputStream.class, I think the expected 
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); // 
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047098#comment-16047098
 ] 

ASF GitHub Bot commented on CLI-274:


Github user coveralls commented on the issue:

https://github.com/apache/commons-cli/pull/12
  

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

Coverage increased (+0.009%) to 96.244% when pulling 
**4f9c95bcb246b64f7f6756cc3840d2061a262fe7 on schaumb:patch-1** into 
**70a392756c713f404fed0e3ddd48aa18ce20485f on apache:master**.



> Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
>  Issue Type: Bug
>  Components: Parser
>Reporter: Béla Schaum
>Priority: Minor
>
> When the user pass option type FileInputStream.class, I think the expected 
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); // 
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047097#comment-16047097
 ] 

ASF GitHub Bot commented on CLI-274:


Github user coveralls commented on the issue:

https://github.com/apache/commons-cli/pull/12
  

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

Coverage increased (+0.009%) to 96.244% when pulling 
**4f9c95bcb246b64f7f6756cc3840d2061a262fe7 on schaumb:patch-1** into 
**70a392756c713f404fed0e3ddd48aa18ce20485f on apache:master**.



> Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
>  Issue Type: Bug
>  Components: Parser
>Reporter: Béla Schaum
>Priority: Minor
>
> When the user pass option type FileInputStream.class, I think the expected 
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); // 
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047086#comment-16047086
 ] 

Sebb commented on TEXT-88:
--

To me a second param of null means "I have not provided any delimiters".
So does omitting the second parameter.
Therefore they should have the same behaviour.

Since the commonest delimiter is whitespace, it's convenient to have that as a 
default if no delimiter array is provided.
This is also what the LANG original states in the Javadoc.

> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty 
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that 
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have 
> been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047060#comment-16047060
 ] 

ASF GitHub Bot commented on CLI-274:


Github user coveralls commented on the issue:

https://github.com/apache/commons-cli/pull/12
  

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

Coverage increased (+0.009%) to 96.244% when pulling 
**1e59d0c2fd1cfee450d0104734307306803a84e0 on schaumb:patch-1** into 
**70a392756c713f404fed0e3ddd48aa18ce20485f on apache:master**.



> Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
>  Issue Type: Bug
>  Components: Parser
>Reporter: Béla Schaum
>Priority: Minor
>
> When the user pass option type FileInputStream.class, I think the expected 
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); // 
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047059#comment-16047059
 ] 

ASF GitHub Bot commented on CLI-274:


Github user coveralls commented on the issue:

https://github.com/apache/commons-cli/pull/12
  

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

Coverage increased (+0.009%) to 96.244% when pulling 
**1e59d0c2fd1cfee450d0104734307306803a84e0 on schaumb:patch-1** into 
**70a392756c713f404fed0e3ddd48aa18ce20485f on apache:master**.



> Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
>  Issue Type: Bug
>  Components: Parser
>Reporter: Béla Schaum
>Priority: Minor
>
> When the user pass option type FileInputStream.class, I think the expected 
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); // 
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-407) Validate Block and Record Sizes

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046995#comment-16046995
 ] 

Simon Spero commented on COMPRESS-407:
--

I've rebased 405 and 407 onto my personal 403 branch.  It make make more sense 
to address all these changes as a whole.

> Validate Block and Record Sizes
> ---
>
> Key: COMPRESS-407
> URL: https://issues.apache.org/jira/browse/COMPRESS-407
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>
> Reject record sizes not equal to 512 bytes; require block sizes to be 
> multiples of 512 bytes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (COMPRESS-410) Remove ZipEncoding implementations introduced to work around problems in jdk 1.4

[Simon Spero (JIRA)]

Simon Spero created COMPRESS-410:


 Summary: Remove   ZipEncoding implementations introduced to work 
around problems in jdk 1.4
 Key: COMPRESS-410
 URL: https://issues.apache.org/jira/browse/COMPRESS-410
 Project: Commons Compress
  Issue Type: Improvement
  Components: Archivers
Affects Versions: 1.14
Reporter: Simon Spero
Priority: Minor


There are several implementations of ZipEncoding that are provided to work 
around missing character sets  in JDK 1.4. 
Since commons-compress requires JDK7 or later, this code is no longer needed. 
As the classes are package private, they can be removed without affecting the 
API. 





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[Arun Vinud (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046970#comment-16046970
 ] 

Arun Vinud  commented on TEXT-88:
-

I feel all these calls should return the same output.

*WordUtils.capitalizeFully("i am fine") --> I Am Fine*

*WordUtils.capitalizeFully("i am fine", null) --> I Am Fine*

*WordUtils.capitalizeFully("i am fine", new char[]{}) --> I am fine* (Assuming 
the latest change yet to be merged)

Its a bit ambiguous to add space as the default delimiter for the first two 
calls  when we pass null for delimiter array but not when we pass empty 
delimiter array. From a developer perspective passing an empty or null for 
delimiter array would essentially mean they don't have or want any delimiters 
and I feel its kind of proactive not necessarily in a good way to consider 
space as delimiter for the first two cases . What you guys think?

> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty 
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that 
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have 
> been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #272: Replaced test with verify

[coveralls]

Github user coveralls commented on the issue:

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

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

Coverage remained the same at 95.173% when pulling 
**51b16af237e167c9c25210a0e872ecbcaed499be on ameyjadiye:mvn-test-verify** into 
**ac3abadf5d338596a2503fc8d18d4e3e1319a79e 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 #272: Replaced test with verify

[ameyjadiye]

GitHub user ameyjadiye opened a pull request:

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

Replaced test with verify



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

$ git pull https://github.com/ameyjadiye/commons-lang mvn-test-verify

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

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


commit 51b16af237e167c9c25210a0e872ecbcaed499be
Author: Amey Jadiye 
Date:   2017-06-12T19:16:27Z

Replaced test with verify




---
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 issue #268: .travis.yml: add oraclejdk9

[ameyjadiye]

Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-lang/pull/268
  
Hmm, how about using docker service for this ? , I have raised same for 
ibmjdk8 https://github.com/apache/commons-lang/pull/271


---
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 issue #268: .travis.yml: add oraclejdk9

[PascalSchumacher]

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/268
  
It is not officially supported, but it is possible.

For example https://github.com/jacoco/jacoco and 
https://github.com/apache/logging-log4j2 use jdk 9 on travis.


---
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] (COLLECTIONS-606) Build status, Coverage status and Maven central in GIT

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046928#comment-16046928
 ] 

ASF GitHub Bot commented on COLLECTIONS-606:


Github user asfgit closed the pull request at:

https://github.com/apache/commons-collections/pull/23


> Build status, Coverage status and Maven central in GIT
> --
>
> Key: COLLECTIONS-606
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-606
> Project: Commons Collections
>  Issue Type: Improvement
>Affects Versions: 4.1
>Reporter: Vamsi
>Assignee: Rob Tompkins
>Priority: Minor
> Fix For: 4.2
>
>
> Add Build status, Coverage status, and Maven central links to README.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1340) Add IBM Java 8 CI checks for Commons Lang

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046927#comment-16046927
 ] 

ASF GitHub Bot commented on LANG-1340:
--

Github user coveralls commented on the issue:

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

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

Coverage increased (+0.01%) to 95.186% when pulling 
**6688a62d28f0be3b972e24b31d35a8f812272a81 on ameyjadiye:master** into 
**ac3abadf5d338596a2503fc8d18d4e3e1319a79e on apache:master**.



> Add IBM Java 8 CI checks for Commons Lang
> -
>
> Key: LANG-1340
> URL: https://issues.apache.org/jira/browse/LANG-1340
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Amey Jadiye
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #271: LANG-1340: Added ibmjdk8 support for travis-ci

[coveralls]

Github user coveralls commented on the issue:

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

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

Coverage increased (+0.01%) to 95.186% when pulling 
**6688a62d28f0be3b972e24b31d35a8f812272a81 on ameyjadiye:master** into 
**ac3abadf5d338596a2503fc8d18d4e3e1319a79e 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.
---

[jira] [Commented] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046917#comment-16046917
 ] 

ASF GitHub Bot commented on CLI-274:


Github user britter commented on a diff in the pull request:

https://github.com/apache/commons-cli/pull/12#discussion_r121493262
  
--- Diff: 
src/test/java/org/apache/commons/cli/PatternOptionBuilderTest.java ---
@@ -159,13 +161,12 @@ public void testURLPattern() throws Exception
 @Test
 public void testExistingFilePattern() throws Exception
 {
-final Options options = PatternOptionBuilder.parsePattern("f<");
+final Options options = PatternOptionBuilder.parsePattern("f Yes, It is null because test.properties does not exist, or not readable. 
This can be made clearer somehow.

Maybe by calling it `non-existing.file`?

> Another task is to find a cross-platform file which is exist (and not 
/dev/null).

You could put add dummy file in `src/test/resources` and use that one.


> Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
>  Issue Type: Bug
>  Components: Parser
>Reporter: Béla Schaum
>Priority: Minor
>
> When the user pass option type FileInputStream.class, I think the expected 
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); // 
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046918#comment-16046918
 ] 

ASF GitHub Bot commented on CLI-274:


Github user britter commented on a diff in the pull request:

https://github.com/apache/commons-cli/pull/12#discussion_r121493262
  
--- Diff: 
src/test/java/org/apache/commons/cli/PatternOptionBuilderTest.java ---
@@ -159,13 +161,12 @@ public void testURLPattern() throws Exception
 @Test
 public void testExistingFilePattern() throws Exception
 {
-final Options options = PatternOptionBuilder.parsePattern("f<");
+final Options options = PatternOptionBuilder.parsePattern("f Yes, It is null because test.properties does not exist, or not readable. 
This can be made clearer somehow.

Maybe by calling it `non-existing.file`?

> Another task is to find a cross-platform file which is exist (and not 
/dev/null).

You could put add dummy file in `src/test/resources` and use that one.


> Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
>  Issue Type: Bug
>  Components: Parser
>Reporter: Béla Schaum
>Priority: Minor
>
> When the user pass option type FileInputStream.class, I think the expected 
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); // 
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LANG-1340) Add IBM Java 8 CI checks for Commons Lang

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046912#comment-16046912
 ] 

ASF GitHub Bot commented on LANG-1340:
--

GitHub user ameyjadiye opened a pull request:

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

LANG-1340: Added ibmjdk8 support for travis-ci

Addition of the ibmjdk8 to Commons Text is successful, so adding it to 
Commons Lang would be an advantage.

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

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

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

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


commit 6688a62d28f0be3b972e24b31d35a8f812272a81
Author: Amey Jadiye 
Date:   2017-06-12T18:31:19Z

LANG-1340: Added ibmjdk8 support for travis-ci




> Add IBM Java 8 CI checks for Commons Lang
> -
>
> Key: LANG-1340
> URL: https://issues.apache.org/jira/browse/LANG-1340
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Amey Jadiye
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #271: LANG-1340: Added ibmjdk8 support for travis-...

[ameyjadiye]

GitHub user ameyjadiye opened a pull request:

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

LANG-1340: Added ibmjdk8 support for travis-ci

Addition of the ibmjdk8 to Commons Text is successful, so adding it to 
Commons Lang would be an advantage.

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

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

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

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


commit 6688a62d28f0be3b972e24b31d35a8f812272a81
Author: Amey Jadiye 
Date:   2017-06-12T18:31:19Z

LANG-1340: Added ibmjdk8 support for travis-ci




---
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] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046910#comment-16046910
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/31
  

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

Coverage decreased (-0.03%) to 84.306% when pulling 
**3a1d29e2474519c3930742cf3000b6323bb426a8 on sesuncedu:COMPRESS-400-REDUX** 
into **0d8ab18c86f4edb38a73de1512483bb5b876bb1f on apache:master**.



> It should be possible for users to create and access extra PAX headers to tar 
> archives 
> ---
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Simon Spero
>Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries.  For 
> example, a tar file containing maven artifacts could have extra headers 
> carrying the groupid, artifactid, version, classifier, etc.  
> If the appropriate prefixes are used, these headers can be extracted to posix 
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra 
> headers, plus modifications to the TarArchive*Stream to save unrecognized 
> headers when reading, and to add any extra headers when writing. 
> I have created a prototype implementation, but have not merged it into my 
> fork of the project.  I don't have full tests written, because I was using 
> gnutar as an oracle.
>  I have also ignored the issue of writing values to standard headers like 
> size, though since the PAX specification states that doing things like 
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm 
> technically in compliance.  The temptation is  to do what was asked, then on 
> close pop up a "Were you sure?" dialog, but that's mean.  I guess I could use 
> this to set the appropriate entry fields if doing so makes sense, but the 
> easiest approach  is to block setting any headers that would be consumed by 
> the tar implementation when reading. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046902#comment-16046902
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user sesuncedu closed the pull request at:

https://github.com/apache/commons-compress/pull/27


> It should be possible for users to create and access extra PAX headers to tar 
> archives 
> ---
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Simon Spero
>Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries.  For 
> example, a tar file containing maven artifacts could have extra headers 
> carrying the groupid, artifactid, version, classifier, etc.  
> If the appropriate prefixes are used, these headers can be extracted to posix 
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra 
> headers, plus modifications to the TarArchive*Stream to save unrecognized 
> headers when reading, and to add any extra headers when writing. 
> I have created a prototype implementation, but have not merged it into my 
> fork of the project.  I don't have full tests written, because I was using 
> gnutar as an oracle.
>  I have also ignored the issue of writing values to standard headers like 
> size, though since the PAX specification states that doing things like 
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm 
> technically in compliance.  The temptation is  to do what was asked, then on 
> close pop up a "Were you sure?" dialog, but that's mean.  I guess I could use 
> this to set the appropriate entry fields if doing so makes sense, but the 
> easiest approach  is to block setting any headers that would be consumed by 
> the tar implementation when reading. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046898#comment-16046898
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

GitHub user sesuncedu opened a pull request:

https://github.com/apache/commons-compress/pull/31

COMPRESS-400 It should be possible for users to create and access extra PAX 
headers to tar archives

Add extra header map to tar archive entry.
Move PAX header processing code from TarArchiveInputStream to 
TarAchiveEntry.
Use same code for processing user supplied extra headers - thus setting 
"size "changes the value of getSize().
Add any extra PAX headers to output map when putting entry in 
TarArchiveOutputStream.
Add simple tests for getting/setting xattr, setting "size", and round 
tripping.

Signed-off-by: Simon Spero 

(cherry picked from commit 1d9b3c8)
Signed-off-by: Simon Spero 

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

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-400-REDUX

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

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


commit 3a1d29e2474519c3930742cf3000b6323bb426a8
Author: Simon Spero 
Date:   2017-06-05T19:58:27Z

COMPRESS-400 It should be possible for users to create and access extra PAX 
headers to tar archives

Add extra header map to tar archive entry.
Move PAX header processing code from TarArchiveInputStream to 
TarAchiveEntry.
Use same code for processing user supplied extra headers - thus setting 
"size "changes the value of getSize().
Add any extra PAX headers to output map when putting entry in 
TarArchiveOutputStream.
Add simple tests for getting/setting xattr, setting "size", and round 
tripping.

Signed-off-by: Simon Spero 

(cherry picked from commit 1d9b3c8)
Signed-off-by: Simon Spero 




> It should be possible for users to create and access extra PAX headers to tar 
> archives 
> ---
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Simon Spero
>Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries.  For 
> example, a tar file containing maven artifacts could have extra headers 
> carrying the groupid, artifactid, version, classifier, etc.  
> If the appropriate prefixes are used, these headers can be extracted to posix 
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra 
> headers, plus modifications to the TarArchive*Stream to save unrecognized 
> headers when reading, and to add any extra headers when writing. 
> I have created a prototype implementation, but have not merged it into my 
> fork of the project.  I don't have full tests written, because I was using 
> gnutar as an oracle.
>  I have also ignored the issue of writing values to standard headers like 
> size, though since the PAX specification states that doing things like 
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm 
> technically in compliance.  The temptation is  to do what was asked, then on 
> close pop up a "Were you sure?" dialog, but that's mean.  I guess I could use 
> this to set the appropriate entry fields if doing so makes sense, but the 
> easiest approach  is to block setting any headers that would be consumed by 
> the tar implementation when reading. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TEXT-67) NumericEntityUnescaper.options - fix TODO

[Pascal Schumacher (JIRA)]

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

Pascal Schumacher updated TEXT-67:
--
Summary: NumericEntityUnescaper.options - fix TODO  (was: 
NumericEntityUnescaper.options - TODO)

> NumericEntityUnescaper.options - fix TODO
> -
>
> Key: TEXT-67
> URL: https://issues.apache.org/jira/browse/TEXT-67
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.0-beta-1
>Reporter: Rob Tompkins
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.2
>
>
> To mitigate having checkstyle errors, we have added this Jira en lieu of the 
> TODO comment in the code.
> Below the JavaDoc for the {{options}} private variable, but above the 
> variable reads:
> bq. Create an OptionsSet class to hide some of the conditional logic below



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TEXT-83) Document that commons-csv should be used in preference to CsvTranslators

[Pascal Schumacher (JIRA)]

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

Pascal Schumacher updated TEXT-83:
--
Description: Document that commons-csv should be used in preference to 
CsvTranslators.  (was: Document that commons-csv should be used in preference 
of CsvTranslators.)

> Document that commons-csv should be used in preference to CsvTranslators
> 
>
> Key: TEXT-83
> URL: https://issues.apache.org/jira/browse/TEXT-83
> Project: Commons Text
>  Issue Type: Task
>Reporter: Amey Jadiye
>Assignee: Rob Tompkins
>Priority: Minor
> Fix For: 1.2
>
>
> Document that commons-csv should be used in preference to CsvTranslators.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TEXT-83) Document that commons-csv should be used in preference to CsvTranslators

[Pascal Schumacher (JIRA)]

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

Pascal Schumacher updated TEXT-83:
--
 Assignee: Rob Tompkins
Fix Version/s: (was: 1.x)
   1.2
  Description: Document that commons-csv should be used in preference of 
CsvTranslators.  (was: Deprecate CsvTranslators from from commons text in favor 
of Commons CSV)

> Document that commons-csv should be used in preference to CsvTranslators
> 
>
> Key: TEXT-83
> URL: https://issues.apache.org/jira/browse/TEXT-83
> Project: Commons Text
>  Issue Type: Task
>Reporter: Amey Jadiye
>Assignee: Rob Tompkins
>Priority: Minor
> Fix For: 1.2
>
>
> Document that commons-csv should be used in preference of CsvTranslators.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (TEXT-83) Document that commons-csv should be used in preference to CsvTranslators

[Pascal Schumacher (JIRA)]

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

Pascal Schumacher resolved TEXT-83.
---
Resolution: Fixed

> Document that commons-csv should be used in preference to CsvTranslators
> 
>
> Key: TEXT-83
> URL: https://issues.apache.org/jira/browse/TEXT-83
> Project: Commons Text
>  Issue Type: Task
>Reporter: Amey Jadiye
>Assignee: Rob Tompkins
>Priority: Minor
> Fix For: 1.2
>
>
> Document that commons-csv should be used in preference of CsvTranslators.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TEXT-83) Document that commons-csv should be used in preference to CsvTranslators

[Pascal Schumacher (JIRA)]

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

Pascal Schumacher updated TEXT-83:
--
Summary: Document that commons-csv should be used in preference to 
CsvTranslators  (was: Document that commons-csv should be used instead of 
CsvTranslators)

> Document that commons-csv should be used in preference to CsvTranslators
> 
>
> Key: TEXT-83
> URL: https://issues.apache.org/jira/browse/TEXT-83
> Project: Commons Text
>  Issue Type: Task
>Reporter: Amey Jadiye
>Priority: Minor
> Fix For: 1.x
>
>
> Deprecate CsvTranslators from from commons text in favor of Commons CSV



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TEXT-83) Document that commons-csv should be used instead of CsvTranslators

[Pascal Schumacher (JIRA)]

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

Pascal Schumacher updated TEXT-83:
--
Summary: Document that commons-csv should be used instead of CsvTranslators 
 (was: Deprecate CsvTranslators from from commons text in favor of Commons CSV)

> Document that commons-csv should be used instead of CsvTranslators
> --
>
> Key: TEXT-83
> URL: https://issues.apache.org/jira/browse/TEXT-83
> Project: Commons Text
>  Issue Type: Task
>Reporter: Amey Jadiye
>Priority: Minor
> Fix For: 1.x
>
>
> Deprecate CsvTranslators from from commons text in favor of Commons CSV



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #268: .travis.yml: add oraclejdk9

[ameyjadiye]

Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-lang/pull/268
  
As per Travis-ci documentation doesnt seems they support oraclejdk9 

https://docs.travis-ci.com/user/languages/java/ 

>The Travis CI environment provides Oracle JDK 7 (default), Oracle JDK 8, 
OpenJDK 6, OpenJDK 7, Gradle 2.0, Maven 3.2 and Ant 1.8, and has sensible 
defaults for projects that use Gradle, Maven or Ant.

Thats why I added Docker Image for ibmjdk8 to Commons text 
https://github.com/apache/commons-text/pull/45


---
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] (COLLECTIONS-606) Build status, Coverage status and Maven central in GIT

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046884#comment-16046884
 ] 

Rob Tompkins commented on COLLECTIONS-606:
--

Note, svn location: 
http://svn.apache.org/repos/asf/commons/proper/collections/trunk/README.md.

> Build status, Coverage status and Maven central in GIT
> --
>
> Key: COLLECTIONS-606
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-606
> Project: Commons Collections
>  Issue Type: Improvement
>Affects Versions: 4.1
>Reporter: Vamsi
>Assignee: Rob Tompkins
>Priority: Minor
> Fix For: 4.2
>
>
> Add Build status, Coverage status, and Maven central links to README.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (COLLECTIONS-606) Build status, Coverage status and Maven central in GIT

[Rob Tompkins (JIRA)]

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

Rob Tompkins resolved COLLECTIONS-606.
--
Resolution: Fixed

Committed in svn 1798499. 

> Build status, Coverage status and Maven central in GIT
> --
>
> Key: COLLECTIONS-606
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-606
> Project: Commons Collections
>  Issue Type: Improvement
>Affects Versions: 4.1
>Reporter: Vamsi
>Assignee: Rob Tompkins
>Priority: Minor
> Fix For: 4.2
>
>
> Add Build status, Coverage status, and Maven central links to README.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (COLLECTIONS-606) Build status, Coverage status and Maven central in GIT

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated COLLECTIONS-606:
-
Affects Version/s: 4.1

> Build status, Coverage status and Maven central in GIT
> --
>
> Key: COLLECTIONS-606
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-606
> Project: Commons Collections
>  Issue Type: Improvement
>Affects Versions: 4.1
>Reporter: Vamsi
>Assignee: Rob Tompkins
>Priority: Minor
> Fix For: 4.2
>
>
> Add Build status, Coverage status, and Maven central links to README.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (COLLECTIONS-606) Build status, Coverage status and Maven central in GIT

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated COLLECTIONS-606:
-
Fix Version/s: 4.2

> Build status, Coverage status and Maven central in GIT
> --
>
> Key: COLLECTIONS-606
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-606
> Project: Commons Collections
>  Issue Type: Improvement
>Affects Versions: 4.1
>Reporter: Vamsi
>Assignee: Rob Tompkins
>Priority: Minor
> Fix For: 4.2
>
>
> Add Build status, Coverage status, and Maven central links to README.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LANG-1340) Add IBM Java 8 CI checks for Commons Lang

[Amey Jadiye (JIRA)]

Amey Jadiye created LANG-1340:
-

 Summary: Add IBM Java 8 CI checks for Commons Lang
 Key: LANG-1340
 URL: https://issues.apache.org/jira/browse/LANG-1340
 Project: Commons Lang
  Issue Type: Improvement
Reporter: Amey Jadiye






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #268: .travis.yml: add oraclejdk9

[PascalSchumacher]

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/268
  
Another problem is that the maven version used by travis does not work with 
jdk 9 as far as I know.


---
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] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046852#comment-16046852
 ] 

ASF GitHub Bot commented on TEXT-88:


GitHub user ameyjadiye opened a pull request:

https://github.com/apache/commons-text/pull/48

TEXT-88: Fixed issue with empty delimiters array with capitalizeFully



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

$ git pull https://github.com/ameyjadiye/commons-text TEXT-88

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

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


commit 0dd69e060be13c596316e878da2c3591b722c015
Author: Amey Jadiye 
Date:   2017-06-12T17:56:46Z

TEXT-88: Fixed issue with empty delimiters array with capitalizeFully




> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty 
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that 
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have 
> been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (COLLECTIONS-606) Build status, Coverage status and Maven central in GIT

[Rob Tompkins (JIRA)]

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

Rob Tompkins updated COLLECTIONS-606:
-
Assignee: Rob Tompkins

> Build status, Coverage status and Maven central in GIT
> --
>
> Key: COLLECTIONS-606
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-606
> Project: Commons Collections
>  Issue Type: Improvement
>Reporter: Vamsi
>Assignee: Rob Tompkins
>Priority: Minor
>
> Add Build status, Coverage status, and Maven central links to README.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046847#comment-16046847
 ] 

ASF GitHub Bot commented on CLI-274:


Github user schaumb commented on a diff in the pull request:

https://github.com/apache/commons-cli/pull/12#discussion_r121406356
  
--- Diff: 
src/test/java/org/apache/commons/cli/PatternOptionBuilderTest.java ---
@@ -159,13 +161,12 @@ public void testURLPattern() throws Exception
 @Test
 public void testExistingFilePattern() throws Exception
 {
-final Options options = PatternOptionBuilder.parsePattern("f<");
+final Options options = PatternOptionBuilder.parsePattern("f Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
>  Issue Type: Bug
>  Components: Parser
>Reporter: Béla Schaum
>Priority: Minor
>
> When the user pass option type FileInputStream.class, I think the expected 
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); // 
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLI-274) Option parser type EXISTING_FILE_VALUE not check file existing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046846#comment-16046846
 ] 

ASF GitHub Bot commented on CLI-274:


Github user schaumb commented on a diff in the pull request:

https://github.com/apache/commons-cli/pull/12#discussion_r121406356
  
--- Diff: 
src/test/java/org/apache/commons/cli/PatternOptionBuilderTest.java ---
@@ -159,13 +161,12 @@ public void testURLPattern() throws Exception
 @Test
 public void testExistingFilePattern() throws Exception
 {
-final Options options = PatternOptionBuilder.parsePattern("f<");
+final Options options = PatternOptionBuilder.parsePattern("f Option parser type EXISTING_FILE_VALUE not check file existing
> --
>
> Key: CLI-274
> URL: https://issues.apache.org/jira/browse/CLI-274
> Project: Commons CLI
>  Issue Type: Bug
>  Components: Parser
>Reporter: Béla Schaum
>Priority: Minor
>
> When the user pass option type FileInputStream.class, I think the expected 
> behavior for the return value is the same type, which the user passed.
> Options options = new Options();
> options.addOption(Option.builder("f").hasArg().type(FileInputStream.class).build());
> CommandLine cline = new DefaultParser().parse(options, args);
> FileInputStream file = (FileInputStream) cline.getParsedOptionValue("f"); // 
> it returns "File" object, without check File exist.
> I attach a solution for it:
> https://github.com/schaumb/commons-cli/commit/abfcc8211f529ab75f3b3edd4a827e484109eb0b



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046838#comment-16046838
 ] 

Sebb commented on TEXT-88:
--

Agreed, should not return string unchanged if there are no delims

> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty 
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that 
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have 
> been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[Amey Jadiye (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046828#comment-16046828
 ] 

Amey Jadiye commented on TEXT-88:
-

agreed, its a obvious bug looking at code.

{code:java}
 public static String capitalizeFully(String str, final char... delimiters) {
final int delimLen = delimiters == null ? -1 : delimiters.length;
if (StringUtils.isEmpty(str) || delimLen == 0) { // BUG IS HERE, if 
length is 0 , returning str as it is.
return str;
}
str = str.toLowerCase();
return capitalize(str, delimiters);
}


{code}

FIX : 

{code:java}
public static String capitalizeFully(String str, final char... delimiters) {
final int delimLen = delimiters == null ? -1 : delimiters.length;
if (StringUtils.isEmpty(str)) {
return str;
}
if (delimLen == 0){
return capitalize(str.toLowerCase(), null);
}
str = str.toLowerCase();
return capitalize(str, delimiters);
}
{code}


> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty 
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that 
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have 
> been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (COLLECTIONS-606) Build status, Coverage status and Maven central in GIT

[Vamsi (JIRA)]

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

Vamsi updated COLLECTIONS-606:
--
Comment: was deleted

(was: [~chtompki] Opened a pull request 
[PR|https://github.com/apache/commons-collections/pull/23]
)

> Build status, Coverage status and Maven central in GIT
> --
>
> Key: COLLECTIONS-606
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-606
> Project: Commons Collections
>  Issue Type: Improvement
>Reporter: Vamsi
>Priority: Minor
>
> Add Build status, Coverage status, and Maven central links to README.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COLLECTIONS-606) Build status, Coverage status and Maven central in GIT

[Vamsi (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046771#comment-16046771
 ] 

Vamsi commented on COLLECTIONS-606:
---

[~chtompki] Opened a pull request 
[PR|https://github.com/apache/commons-collections/pull/23]


> Build status, Coverage status and Maven central in GIT
> --
>
> Key: COLLECTIONS-606
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-606
> Project: Commons Collections
>  Issue Type: Improvement
>Reporter: Vamsi
>Priority: Minor
>
> Add Build status, Coverage status, and Maven central links to README.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COLLECTIONS-606) Build status, Coverage status and Maven central in GIT

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046769#comment-16046769
 ] 

ASF GitHub Bot commented on COLLECTIONS-606:


GitHub user vamsi-kavuri opened a pull request:

https://github.com/apache/commons-collections/pull/23

COLLECTIONS-606:Added build and coverage status

@chtompki Please take a look at it


Resolves:
https://issues.apache.org/jira/browse/COLLECTIONS-606

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

$ git pull https://github.com/vamsi-kavuri/commons-collections trunk

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

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


commit bcaa1484b830a45b5ae8f975ba8816a48cc462ed
Author: Kavuri, Vamsi 
Date:   2017-06-12T16:37:26Z

COLLECTIONS-606:Added build and coverage status

commit 676c353e0c24450ac4fc1435db1b8e0df3384e3b
Author: Vamsi 
Date:   2017-06-12T16:43:03Z

Merge pull request #1 from vamsi-kavuri/COLLECTIONS-606-BuildStatus

COLLECTIONS-606:Added build and coverage status




> Build status, Coverage status and Maven central in GIT
> --
>
> Key: COLLECTIONS-606
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-606
> Project: Commons Collections
>  Issue Type: Improvement
>Reporter: Vamsi
>Priority: Minor
>
> Add Build status, Coverage status, and Maven central links to README.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (COLLECTIONS-606) Build status, Coverage status and Maven central in GIT

[Vamsi (JIRA)]

Vamsi created COLLECTIONS-606:
-

 Summary: Build status, Coverage status and Maven central in GIT
 Key: COLLECTIONS-606
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-606
 Project: Commons Collections
  Issue Type: Improvement
Reporter: Vamsi
Priority: Minor


Add Build status, Coverage status, and Maven central links to README.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[Rob Tompkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046680#comment-16046680
 ] 

Rob Tompkins commented on TEXT-88:
--

[~s...@apache.org] and [~arunvinud] - does this seem appropriate?

> WordUtils.capitalizeFully behaves in a counterintuitive manner with empty 
> delimiter array.
> --
>
> Key: TEXT-88
> URL: https://issues.apache.org/jira/browse/TEXT-88
> Project: Commons Text
>  Issue Type: Bug
>Reporter: Rob Tompkins
>
> As discussed in TEXT-85, it seems that 
> {code:java}
> WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
> {code}
> Both Sebb and Arun think that this is odd and that the letter "i" should have 
> been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[Rob Tompkins (JIRA)]

Rob Tompkins created TEXT-88:


 Summary: WordUtils.capitalizeFully behaves in a counterintuitive 
manner with empty delimiter array.
 Key: TEXT-88
 URL: https://issues.apache.org/jira/browse/TEXT-88
 Project: Commons Text
  Issue Type: Bug
Reporter: Rob Tompkins


As discussed in TEXT-85, it seems that 
{code:java}
WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine
{code}
Both Sebb and Arun think that this is odd and that the letter "i" should have 
been capitalized resulting in the output {{I am fine}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046661#comment-16046661
 ] 

ASF GitHub Bot commented on COMPRESS-400:
-

Github user bodewig commented on the issue:

https://github.com/apache/commons-compress/pull/27
  
Thanks, do you think you could re-create the PR without the commits that 
belong to #26 ?


> It should be possible for users to create and access extra PAX headers to tar 
> archives 
> ---
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Simon Spero
>Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries.  For 
> example, a tar file containing maven artifacts could have extra headers 
> carrying the groupid, artifactid, version, classifier, etc.  
> If the appropriate prefixes are used, these headers can be extracted to posix 
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra 
> headers, plus modifications to the TarArchive*Stream to save unrecognized 
> headers when reading, and to add any extra headers when writing. 
> I have created a prototype implementation, but have not merged it into my 
> fork of the project.  I don't have full tests written, because I was using 
> gnutar as an oracle.
>  I have also ignored the issue of writing values to standard headers like 
> size, though since the PAX specification states that doing things like 
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm 
> technically in compliance.  The temptation is  to do what was asked, then on 
> close pop up a "Were you sure?" dialog, but that's mean.  I guess I could use 
> this to set the appropriate entry fields if doing so makes sense, but the 
> easiest approach  is to block setting any headers that would be consumed by 
> the tar implementation when reading. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-85) Create CaseUtils class. Add toCamelCase

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046644#comment-16046644
 ] 

ASF GitHub Bot commented on TEXT-85:


Github user arunvinudss commented on a diff in the pull request:

https://github.com/apache/commons-text/pull/46#discussion_r121417851
  
--- Diff: src/main/java/org/apache/commons/text/CaseUtils.java ---
@@ -0,0 +1,140 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.text;
+
+import org.apache.commons.lang3.StringUtils;
+
+import java.util.HashSet;
+import java.util.Set;
+
+/**
+ * Case manipulation operations on Strings that contain words.
+ *
+ * This class tries to handle null input gracefully.
+ * An exception will not be thrown for a null input.
+ * Each method documents its behaviour in more detail.
+ *
+ * @since 1.0
+ */
+public class CaseUtils {
+
+/**
+ * CaseUtils instances should NOT be constructed in
+ * standard programming. Instead, the class should be used as
+ * CaseUtils.toCamelCase("foo bar", true, new 
char[]{'-'});.
+ * 
+ * This constructor is public to permit tools that require a 
JavaBean
+ * instance to operate.
+ */
+public CaseUtils() {
+super();
+}
+
+// Camel Case
+
//---
+/**
+ * Converts all the delimiter separated words in a String into 
camelCase,
+ * that is each word is made up of a titlecase character and then a 
series of
+ * lowercase characters. The  
+ *
+ * The delimiters represent a set of characters understood to 
separate words.
+ * The first non-delimiter character after a delimiter will be 
capitalized. The first String
+ * character may or may not be capitalized and it's determined by the 
user input for capitalizeFirstLetter
+ * variable.
+ *
+ * A null input String returns null.
+ * Capitalization uses the Unicode title case, normally equivalent to
+ * upper case.
+ *
+ * 
+ * CaseUtils.toCamelCase(null, false) 
= null
+ * CaseUtils.toCamelCase("", false, *)
= ""
+ * CaseUtils.toCamelCase(*, false, null)  
= *
+ * CaseUtils.toCamelCase(*, true, new char[0])
= *
+ * CaseUtils.toCamelCase("To.Camel.Case", false, new char[]{'.'}) 
= "toCamelCase"
+ * CaseUtils.toCamelCase(" to @ Camel case", true, new char[]{'@'})   
= "toCamelCase"
+ * CaseUtils.toCamelCase(" @to @ Camel case", false, new char[]{'@'}) 
= "toCamelCase"
+ * 
+ *
+ * @param str  the String to be converted to camelCase, may be null
+ * @param capitalizeFirstLetter boolean that determines if the first 
character of first word should be title case.
+ * @param delimiters  set of characters to determine capitalization, 
null and/or empty array means whitespace
+ * @return camelCase of String, null if null String input
+ */
+public static String toCamelCase(String str, boolean 
capitalizeFirstLetter, final char... delimiters) {
--- End diff --

I am a bit biased towards using String instead of CharSequence . Yes 
CharSequence allows us to pass String Buffers and builders and other types as 
input potentially increasing the scope of the function but considering the 
nature of work we do in this particular method it may not necessarily be a good 
idea. My basic contention is that the minute we call toString() on a 
charSequence  to do any sort of manipulation it becomes a costly operation and 
we may lose performance . 


> Create CaseUtils class. Add toCamelCase
> ---
>
> Key: TEXT-85
> URL: https://issues.apache.org/jira/browse/TEXT-85

[jira] [Updated] (TEXT-87) StrBuilder Add Prefix Optimization

[BELUGA BEHR (JIRA)]

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

BELUGA BEHR updated TEXT-87:

Description: 
As a nice differentiation to Java's String Builder, please add an optimization 
for pre-appending.  Create the buffer a little larger and keep a pointer at the 
0-index of the buffer so that pre-appending isn't necessarily a copy operations 
and instead is simply a pointer update and an array value update.

{code}

public StrBuilder(int initialCapacity, int preCapacity);

// So that on something like this, insert(0, 'A'), isn't a guaranteed array copy

/**
 * Inserts the value into this builder.
 *
 * @param index  the index to add at, must be valid
 * @param value  the value to insert
 * @return this, to enable chaining
 * @throws IndexOutOfBoundsException if the index is invalid
 */
public StrBuilder insert(final int index, final char value) {
validateIndex(index);
// if index == 0 and (bufIndex != 0)
// buffer[--bufIndexindex] = value;
// return this;
ensureCapacity(size + 1);
System.arraycopy(buffer, index, buffer, index + 1, size - index);
buffer[index] = value;
size++;
return this;
}
{code}

  was:
As a nice differentiation to Java's String Builder, please add an optimization 
for pre-appending.  Create the buffer a little larger and keep a pointer at the 
0-index of the buffer so that pre-appending isn't necessarily a copy operations 
and instead is simply a pointer update and an array value update.

{code}

public StrBuilder(int initialCapacity, int preCapacity);

// So that on something like this, insert(0, 'A'), isn't a guaranteed array copy

/**
 * Inserts the value into this builder.
 *
 * @param index  the index to add at, must be valid
 * @param value  the value to insert
 * @return this, to enable chaining
 * @throws IndexOutOfBoundsException if the index is invalid
 */
public StrBuilder insert(final int index, final char value) {
validateIndex(index);
// if index == 0 and (bufIndex != 0)
// buffer[bufIndexindex--] = value;
// return this;
ensureCapacity(size + 1);
System.arraycopy(buffer, index, buffer, index + 1, size - index);
buffer[index] = value;
size++;
return this;
}
{code}


> StrBuilder Add Prefix Optimization
> --
>
> Key: TEXT-87
> URL: https://issues.apache.org/jira/browse/TEXT-87
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: BELUGA BEHR
>Priority: Trivial
>
> As a nice differentiation to Java's String Builder, please add an 
> optimization for pre-appending.  Create the buffer a little larger and keep a 
> pointer at the 0-index of the buffer so that pre-appending isn't necessarily 
> a copy operations and instead is simply a pointer update and an array value 
> update.
> {code}
> public StrBuilder(int initialCapacity, int preCapacity);
> // So that on something like this, insert(0, 'A'), isn't a guaranteed array 
> copy
> /**
>  * Inserts the value into this builder.
>  *
>  * @param index  the index to add at, must be valid
>  * @param value  the value to insert
>  * @return this, to enable chaining
>  * @throws IndexOutOfBoundsException if the index is invalid
>  */
> public StrBuilder insert(final int index, final char value) {
> validateIndex(index);
> // if index == 0 and (bufIndex != 0)
> // buffer[--bufIndexindex] = value;
> // return this;
> ensureCapacity(size + 1);
> System.arraycopy(buffer, index, buffer, index + 1, size - index);
> buffer[index] = value;
> size++;
> return this;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TEXT-87) StrBuilder Add Prefix Optimization

[BELUGA BEHR (JIRA)]

BELUGA BEHR created TEXT-87:
---

 Summary: StrBuilder Add Prefix Optimization
 Key: TEXT-87
 URL: https://issues.apache.org/jira/browse/TEXT-87
 Project: Commons Text
  Issue Type: New Feature
Reporter: BELUGA BEHR
Priority: Trivial


As a nice differentiation to Java's String Builder, please add an optimization 
for pre-appending.  Create the buffer a little larger and keep a pointer at the 
0-index of the buffer so that pre-appending isn't necessarily a copy operations 
and instead is simply a pointer update and an array value update.

{code}

public StrBuilder(int initialCapacity, int preCapacity);

// So that on something like this, insert(0, 'A'), isn't a guaranteed array copy

/**
 * Inserts the value into this builder.
 *
 * @param index  the index to add at, must be valid
 * @param value  the value to insert
 * @return this, to enable chaining
 * @throws IndexOutOfBoundsException if the index is invalid
 */
public StrBuilder insert(final int index, final char value) {
validateIndex(index);
// if index == 0 and (bufIndex != 0)
// buffer[bufIndexindex--] = value;
// return this;
ensureCapacity(size + 1);
System.arraycopy(buffer, index, buffer, index + 1, size - index);
buffer[index] = value;
size++;
return this;
}
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-85) Create CaseUtils class. Add toCamelCase

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046622#comment-16046622
 ] 

ASF GitHub Bot commented on TEXT-85:


Github user arunvinudss commented on a diff in the pull request:

https://github.com/apache/commons-text/pull/46#discussion_r121408959
  
--- Diff: src/main/java/org/apache/commons/text/CaseUtils.java ---
@@ -0,0 +1,140 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.text;
+
+import org.apache.commons.lang3.StringUtils;
+
+import java.util.HashSet;
+import java.util.Set;
+
+/**
+ * Case manipulation operations on Strings that contain words.
+ *
+ * This class tries to handle null input gracefully.
+ * An exception will not be thrown for a null input.
+ * Each method documents its behaviour in more detail.
+ *
+ * @since 1.0
+ */
+public class CaseUtils {
+
+/**
+ * CaseUtils instances should NOT be constructed in
+ * standard programming. Instead, the class should be used as
+ * CaseUtils.toCamelCase("foo bar", true, new 
char[]{'-'});.
+ * 
+ * This constructor is public to permit tools that require a 
JavaBean
+ * instance to operate.
+ */
+public CaseUtils() {
+super();
+}
+
+// Camel Case
+
//---
+/**
+ * Converts all the delimiter separated words in a String into 
camelCase,
+ * that is each word is made up of a titlecase character and then a 
series of
+ * lowercase characters. The  
+ *
+ * The delimiters represent a set of characters understood to 
separate words.
+ * The first non-delimiter character after a delimiter will be 
capitalized. The first String
+ * character may or may not be capitalized and it's determined by the 
user input for capitalizeFirstLetter
+ * variable.
+ *
+ * A null input String returns null.
+ * Capitalization uses the Unicode title case, normally equivalent to
+ * upper case.
+ *
+ * 
+ * CaseUtils.toCamelCase(null, false) 
= null
+ * CaseUtils.toCamelCase("", false, *)
= ""
+ * CaseUtils.toCamelCase(*, false, null)  
= *
+ * CaseUtils.toCamelCase(*, true, new char[0])
= *
+ * CaseUtils.toCamelCase("To.Camel.Case", false, new char[]{'.'}) 
= "toCamelCase"
+ * CaseUtils.toCamelCase(" to @ Camel case", true, new char[]{'@'})   
= "toCamelCase"
+ * CaseUtils.toCamelCase(" @to @ Camel case", false, new char[]{'@'}) 
= "toCamelCase"
+ * 
+ *
+ * @param str  the String to be converted to camelCase, may be null
+ * @param capitalizeFirstLetter boolean that determines if the first 
character of first word should be title case.
+ * @param delimiters  set of characters to determine capitalization, 
null and/or empty array means whitespace
+ * @return camelCase of String, null if null String input
+ */
+public static String toCamelCase(String str, boolean 
capitalizeFirstLetter, final char... delimiters) {
--- End diff --

Yes the boolean should be final not sure why I missed that . The input 
string is not final as you mentioned  I change it to lower case inside the 
method .


> Create CaseUtils class. Add toCamelCase
> ---
>
> Key: TEXT-85
> URL: https://issues.apache.org/jira/browse/TEXT-85
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>
> Based on the conversation here:
> http://markmail.org/message/7nvizsbykvxpr7g5
> We wish to have a {{toCamelCase}} method. The suggestion is to create a 
> {{CaseUtils}} class.
> 

[jira] [Commented] (TEXT-85) Create CaseUtils class. Add toCamelCase

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046623#comment-16046623
 ] 

ASF GitHub Bot commented on TEXT-85:


Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/46
  
Regarding the `WordUtils.capitalizeFully`, let's open that discussion up in 
a new Jira. I'll do that now. I think those questions are quite valid.


> Create CaseUtils class. Add toCamelCase
> ---
>
> Key: TEXT-85
> URL: https://issues.apache.org/jira/browse/TEXT-85
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>
> Based on the conversation here:
> http://markmail.org/message/7nvizsbykvxpr7g5
> We wish to have a {{toCamelCase}} method. The suggestion is to create a 
> {{CaseUtils}} class.
> I wonder if we should think about deprecating the case management in 
> {{WordUtils}} and move it over? Maybe, maybe not.
> I would think our method signature would look something like:
> {code}
> String toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)
> {code}
> potentially with {{String}} replaced with {{CharSequence}}.
> Lastly, {{WordUtils.capitalizeFully(String str, final char... delimiters)}} 
> might be a good starting point. 
> https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/WordUtils.java#L467-L499



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-85) Create CaseUtils class. Add toCamelCase

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046615#comment-16046615
 ] 

ASF GitHub Bot commented on TEXT-85:


Github user arunvinudss commented on a diff in the pull request:

https://github.com/apache/commons-text/pull/46#discussion_r121406140
  
--- Diff: src/main/java/org/apache/commons/text/CaseUtils.java ---
@@ -0,0 +1,140 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.text;
+
+import org.apache.commons.lang3.StringUtils;
+
+import java.util.HashSet;
+import java.util.Set;
+
+/**
+ * Case manipulation operations on Strings that contain words.
+ *
+ * This class tries to handle null input gracefully.
+ * An exception will not be thrown for a null input.
+ * Each method documents its behaviour in more detail.
+ *
+ * @since 1.0
+ */
+public class CaseUtils {
+
+/**
+ * CaseUtils instances should NOT be constructed in
+ * standard programming. Instead, the class should be used as
+ * CaseUtils.toCamelCase("foo bar", true, new 
char[]{'-'});.
+ * 
+ * This constructor is public to permit tools that require a 
JavaBean
+ * instance to operate.
+ */
+public CaseUtils() {
+super();
+}
+
+// Camel Case
+
//---
+/**
+ * Converts all the delimiter separated words in a String into 
camelCase,
+ * that is each word is made up of a titlecase character and then a 
series of
+ * lowercase characters. The  
+ *
+ * The delimiters represent a set of characters understood to 
separate words.
+ * The first non-delimiter character after a delimiter will be 
capitalized. The first String
+ * character may or may not be capitalized and it's determined by the 
user input for capitalizeFirstLetter
+ * variable.
+ *
+ * A null input String returns null.
+ * Capitalization uses the Unicode title case, normally equivalent to
+ * upper case.
+ *
+ * 
+ * CaseUtils.toCamelCase(null, false) 
= null
+ * CaseUtils.toCamelCase("", false, *)
= ""
+ * CaseUtils.toCamelCase(*, false, null)  
= *
+ * CaseUtils.toCamelCase(*, true, new char[0])
= *
+ * CaseUtils.toCamelCase("To.Camel.Case", false, new char[]{'.'}) 
= "toCamelCase"
+ * CaseUtils.toCamelCase(" to @ Camel case", true, new char[]{'@'})   
= "toCamelCase"
--- End diff --

Yes it's a documentation error I will update it . 


> Create CaseUtils class. Add toCamelCase
> ---
>
> Key: TEXT-85
> URL: https://issues.apache.org/jira/browse/TEXT-85
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>
> Based on the conversation here:
> http://markmail.org/message/7nvizsbykvxpr7g5
> We wish to have a {{toCamelCase}} method. The suggestion is to create a 
> {{CaseUtils}} class.
> I wonder if we should think about deprecating the case management in 
> {{WordUtils}} and move it over? Maybe, maybe not.
> I would think our method signature would look something like:
> {code}
> String toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)
> {code}
> potentially with {{String}} replaced with {{CharSequence}}.
> Lastly, {{WordUtils.capitalizeFully(String str, final char... delimiters)}} 
> might be a good starting point. 
> https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/WordUtils.java#L467-L499



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TEXT-86) StrBuilder Add New Replace Method

[BELUGA BEHR (JIRA)]

BELUGA BEHR created TEXT-86:
---

 Summary: StrBuilder Add New Replace Method
 Key: TEXT-86
 URL: https://issues.apache.org/jira/browse/TEXT-86
 Project: Commons Text
  Issue Type: New Feature
Reporter: BELUGA BEHR
Priority: Minor


I was looking at some code and thought TEXT might help.  Please add to 
{{org.apache.commons.text.StrBuilder}} a new method signature:

{code}
replaceAll(char search, String replaceStr)
{code}

This would be helpful for escaping individual characters:

{code}
  /*
   * (non-Javadoc)
   *
   * @see java.sql.PreparedStatement#setString(int, java.lang.String)
   */

  public void setString(int parameterIndex, String x) throws SQLException {
 x=x.replace("'", "\\'");
 this.parameters.put(parameterIndex,"'"+x+"'");
  }
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (COMPRESS-406) BUILDING.md is missing license header

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved COMPRESS-406.
-
   Resolution: Fixed
Fix Version/s: 1.15

fixed, thanks!

> BUILDING.md is missing license header 
> --
>
> Key: COMPRESS-406
> URL: https://issues.apache.org/jira/browse/COMPRESS-406
> Project: Commons Compress
>  Issue Type: Bug
>Reporter: Simon Spero
> Fix For: 1.15
>
>
> There is no license header in BUILDING.md. 
> This angers the rat



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-406) BUILDING.md is missing license header

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046606#comment-16046606
 ] 

ASF GitHub Bot commented on COMPRESS-406:
-

Github user asfgit closed the pull request at:

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


> BUILDING.md is missing license header 
> --
>
> Key: COMPRESS-406
> URL: https://issues.apache.org/jira/browse/COMPRESS-406
> Project: Commons Compress
>  Issue Type: Bug
>Reporter: Simon Spero
> Fix For: 1.15
>
>
> There is no license header in BUILDING.md. 
> This angers the rat



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-85) Create CaseUtils class. Add toCamelCase

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046514#comment-16046514
 ] 

ASF GitHub Bot commented on TEXT-85:


Github user chtompki commented on a diff in the pull request:

https://github.com/apache/commons-text/pull/46#discussion_r121380270
  
--- Diff: src/main/java/org/apache/commons/text/CaseUtils.java ---
@@ -0,0 +1,140 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.text;
+
+import org.apache.commons.lang3.StringUtils;
+
+import java.util.HashSet;
+import java.util.Set;
+
+/**
+ * Case manipulation operations on Strings that contain words.
+ *
+ * This class tries to handle null input gracefully.
+ * An exception will not be thrown for a null input.
+ * Each method documents its behaviour in more detail.
+ *
+ * @since 1.0
+ */
+public class CaseUtils {
+
+/**
+ * CaseUtils instances should NOT be constructed in
+ * standard programming. Instead, the class should be used as
+ * CaseUtils.toCamelCase("foo bar", true, new 
char[]{'-'});.
+ * 
+ * This constructor is public to permit tools that require a 
JavaBean
+ * instance to operate.
+ */
+public CaseUtils() {
+super();
+}
+
+// Camel Case
+
//---
+/**
+ * Converts all the delimiter separated words in a String into 
camelCase,
+ * that is each word is made up of a titlecase character and then a 
series of
+ * lowercase characters. The  
+ *
+ * The delimiters represent a set of characters understood to 
separate words.
+ * The first non-delimiter character after a delimiter will be 
capitalized. The first String
+ * character may or may not be capitalized and it's determined by the 
user input for capitalizeFirstLetter
+ * variable.
+ *
+ * A null input String returns null.
+ * Capitalization uses the Unicode title case, normally equivalent to
+ * upper case.
+ *
--- End diff --

I wonder if, like in 
[`Character.toUpperCase`](https://docs.oracle.com/javase/8/docs/api/java/lang/Character.html#toUpperCase-char-),
 we should document that we are not locale based which I support. Adding in 
`Locale` to the mix throws added complexity that may not be needed. Or document 
that we're relying on `Character.toTitleCase` which has no `Locale` based 
analogue in `String`.


> Create CaseUtils class. Add toCamelCase
> ---
>
> Key: TEXT-85
> URL: https://issues.apache.org/jira/browse/TEXT-85
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>
> Based on the conversation here:
> http://markmail.org/message/7nvizsbykvxpr7g5
> We wish to have a {{toCamelCase}} method. The suggestion is to create a 
> {{CaseUtils}} class.
> I wonder if we should think about deprecating the case management in 
> {{WordUtils}} and move it over? Maybe, maybe not.
> I would think our method signature would look something like:
> {code}
> String toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)
> {code}
> potentially with {{String}} replaced with {{CharSequence}}.
> Lastly, {{WordUtils.capitalizeFully(String str, final char... delimiters)}} 
> might be a good starting point. 
> https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/WordUtils.java#L467-L499



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-85) Create CaseUtils class. Add toCamelCase

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046516#comment-16046516
 ] 

ASF GitHub Bot commented on TEXT-85:


Github user chtompki commented on a diff in the pull request:

https://github.com/apache/commons-text/pull/46#discussion_r121380327
  
--- Diff: src/main/java/org/apache/commons/text/CaseUtils.java ---
@@ -0,0 +1,140 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.text;
+
+import org.apache.commons.lang3.StringUtils;
+
+import java.util.HashSet;
+import java.util.Set;
+
+/**
+ * Case manipulation operations on Strings that contain words.
+ *
+ * This class tries to handle null input gracefully.
+ * An exception will not be thrown for a null input.
+ * Each method documents its behaviour in more detail.
+ *
+ * @since 1.0
+ */
+public class CaseUtils {
+
+/**
+ * CaseUtils instances should NOT be constructed in
+ * standard programming. Instead, the class should be used as
+ * CaseUtils.toCamelCase("foo bar", true, new 
char[]{'-'});.
+ * 
+ * This constructor is public to permit tools that require a 
JavaBean
+ * instance to operate.
+ */
+public CaseUtils() {
+super();
+}
+
+// Camel Case
+
//---
+/**
+ * Converts all the delimiter separated words in a String into 
camelCase,
+ * that is each word is made up of a titlecase character and then a 
series of
+ * lowercase characters. The  
+ *
+ * The delimiters represent a set of characters understood to 
separate words.
+ * The first non-delimiter character after a delimiter will be 
capitalized. The first String
+ * character may or may not be capitalized and it's determined by the 
user input for capitalizeFirstLetter
+ * variable.
+ *
+ * A null input String returns null.
+ * Capitalization uses the Unicode title case, normally equivalent to
+ * upper case.
+ *
+ * 
+ * CaseUtils.toCamelCase(null, false) 
= null
+ * CaseUtils.toCamelCase("", false, *)
= ""
+ * CaseUtils.toCamelCase(*, false, null)  
= *
+ * CaseUtils.toCamelCase(*, true, new char[0])
= *
+ * CaseUtils.toCamelCase("To.Camel.Case", false, new char[]{'.'}) 
= "toCamelCase"
+ * CaseUtils.toCamelCase(" to @ Camel case", true, new char[]{'@'})   
= "toCamelCase"
+ * CaseUtils.toCamelCase(" @to @ Camel case", false, new char[]{'@'}) 
= "toCamelCase"
+ * 
+ *
+ * @param str  the String to be converted to camelCase, may be null
+ * @param capitalizeFirstLetter boolean that determines if the first 
character of first word should be title case.
+ * @param delimiters  set of characters to determine capitalization, 
null and/or empty array means whitespace
+ * @return camelCase of String, null if null String input
+ */
+public static String toCamelCase(String str, boolean 
capitalizeFirstLetter, final char... delimiters) {
+if (StringUtils.isEmpty(str)) {
+return str;
+}
+str = str.toLowerCase();
+int strLen = str.length();
+int [] newCodePoints = new int[strLen];
+int outOffset = 0;
+Set delimiterSet = generateDelimiterSet(delimiters);
+boolean capitalizeNext = false;
+if (capitalizeFirstLetter) {
+capitalizeNext = true;
+}
+for (int index = 0; index < strLen;) {
+final int codePoint = str.codePointAt(index);
+
+if (delimiterSet.contains(codePoint)) {
+capitalizeNext = true;
+

[jira] [Commented] (TEXT-85) Create CaseUtils class. Add toCamelCase

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046513#comment-16046513
 ] 

ASF GitHub Bot commented on TEXT-85:


Github user chtompki commented on a diff in the pull request:

https://github.com/apache/commons-text/pull/46#discussion_r121376021
  
--- Diff: src/main/java/org/apache/commons/text/CaseUtils.java ---
@@ -0,0 +1,140 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.text;
+
+import org.apache.commons.lang3.StringUtils;
+
+import java.util.HashSet;
+import java.util.Set;
+
+/**
+ * Case manipulation operations on Strings that contain words.
+ *
+ * This class tries to handle null input gracefully.
+ * An exception will not be thrown for a null input.
+ * Each method documents its behaviour in more detail.
+ *
+ * @since 1.0
+ */
+public class CaseUtils {
+
+/**
+ * CaseUtils instances should NOT be constructed in
+ * standard programming. Instead, the class should be used as
+ * CaseUtils.toCamelCase("foo bar", true, new 
char[]{'-'});.
+ * 
+ * This constructor is public to permit tools that require a 
JavaBean
+ * instance to operate.
+ */
+public CaseUtils() {
+super();
+}
+
+// Camel Case
+
//---
+/**
+ * Converts all the delimiter separated words in a String into 
camelCase,
+ * that is each word is made up of a titlecase character and then a 
series of
+ * lowercase characters. The  
+ *
+ * The delimiters represent a set of characters understood to 
separate words.
+ * The first non-delimiter character after a delimiter will be 
capitalized. The first String
+ * character may or may not be capitalized and it's determined by the 
user input for capitalizeFirstLetter
+ * variable.
+ *
+ * A null input String returns null.
+ * Capitalization uses the Unicode title case, normally equivalent to
+ * upper case.
+ *
+ * 
+ * CaseUtils.toCamelCase(null, false) 
= null
+ * CaseUtils.toCamelCase("", false, *)
= ""
+ * CaseUtils.toCamelCase(*, false, null)  
= *
+ * CaseUtils.toCamelCase(*, true, new char[0])
= *
+ * CaseUtils.toCamelCase("To.Camel.Case", false, new char[]{'.'}) 
= "toCamelCase"
+ * CaseUtils.toCamelCase(" to @ Camel case", true, new char[]{'@'})   
= "toCamelCase"
--- End diff --

After looking at the tests, this appears to be merely a documentation error.


> Create CaseUtils class. Add toCamelCase
> ---
>
> Key: TEXT-85
> URL: https://issues.apache.org/jira/browse/TEXT-85
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>
> Based on the conversation here:
> http://markmail.org/message/7nvizsbykvxpr7g5
> We wish to have a {{toCamelCase}} method. The suggestion is to create a 
> {{CaseUtils}} class.
> I wonder if we should think about deprecating the case management in 
> {{WordUtils}} and move it over? Maybe, maybe not.
> I would think our method signature would look something like:
> {code}
> String toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)
> {code}
> potentially with {{String}} replaced with {{CharSequence}}.
> Lastly, {{WordUtils.capitalizeFully(String str, final char... delimiters)}} 
> might be a good starting point. 
> https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/WordUtils.java#L467-L499



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-85) Create CaseUtils class. Add toCamelCase

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046520#comment-16046520
 ] 

ASF GitHub Bot commented on TEXT-85:


Github user chtompki commented on a diff in the pull request:

https://github.com/apache/commons-text/pull/46#discussion_r121376797
  
--- Diff: src/main/java/org/apache/commons/text/CaseUtils.java ---
@@ -0,0 +1,140 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.text;
+
+import org.apache.commons.lang3.StringUtils;
+
+import java.util.HashSet;
+import java.util.Set;
+
+/**
+ * Case manipulation operations on Strings that contain words.
+ *
+ * This class tries to handle null input gracefully.
+ * An exception will not be thrown for a null input.
+ * Each method documents its behaviour in more detail.
+ *
+ * @since 1.0
+ */
+public class CaseUtils {
+
+/**
+ * CaseUtils instances should NOT be constructed in
+ * standard programming. Instead, the class should be used as
+ * CaseUtils.toCamelCase("foo bar", true, new 
char[]{'-'});.
+ * 
+ * This constructor is public to permit tools that require a 
JavaBean
+ * instance to operate.
+ */
+public CaseUtils() {
+super();
+}
+
+// Camel Case
+
//---
+/**
+ * Converts all the delimiter separated words in a String into 
camelCase,
+ * that is each word is made up of a titlecase character and then a 
series of
+ * lowercase characters. The  
+ *
+ * The delimiters represent a set of characters understood to 
separate words.
+ * The first non-delimiter character after a delimiter will be 
capitalized. The first String
+ * character may or may not be capitalized and it's determined by the 
user input for capitalizeFirstLetter
+ * variable.
+ *
+ * A null input String returns null.
+ * Capitalization uses the Unicode title case, normally equivalent to
+ * upper case.
+ *
+ * 
+ * CaseUtils.toCamelCase(null, false) 
= null
+ * CaseUtils.toCamelCase("", false, *)
= ""
+ * CaseUtils.toCamelCase(*, false, null)  
= *
+ * CaseUtils.toCamelCase(*, true, new char[0])
= *
+ * CaseUtils.toCamelCase("To.Camel.Case", false, new char[]{'.'}) 
= "toCamelCase"
+ * CaseUtils.toCamelCase(" to @ Camel case", true, new char[]{'@'})   
= "toCamelCase"
+ * CaseUtils.toCamelCase(" @to @ Camel case", false, new char[]{'@'}) 
= "toCamelCase"
+ * 
+ *
+ * @param str  the String to be converted to camelCase, may be null
+ * @param capitalizeFirstLetter boolean that determines if the first 
character of first word should be title case.
+ * @param delimiters  set of characters to determine capitalization, 
null and/or empty array means whitespace
+ * @return camelCase of String, null if null String input
+ */
+public static String toCamelCase(String str, boolean 
capitalizeFirstLetter, final char... delimiters) {
--- End diff --

I think that we'll want:
```java
public static String toCamelCase(final String str, final boolean 
capitalizeFirstLetter, final char... delimiters)
```
but I see that you've fiddled with the `str` variable below. So I'm open to 
discussion on that point.

Generally, I'm torn on whether to have the signature be:
```java
public static String toCamelCase(final String str, final boolean 
capitalizeFirstLetter, final char... delimiters);
```
or
```java
public static String toCamelCase(final CharSequence str, final boolean 
capitalizeFirstLetter, final char... delimiters);
```


> Create CaseUtils class. Add toCamelCase

[jira] [Commented] (TEXT-85) Create CaseUtils class. Add toCamelCase

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046517#comment-16046517
 ] 

ASF GitHub Bot commented on TEXT-85:


Github user chtompki commented on a diff in the pull request:

https://github.com/apache/commons-text/pull/46#discussion_r121374008
  
--- Diff: src/main/java/org/apache/commons/text/CaseUtils.java ---
@@ -0,0 +1,140 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.text;
+
+import org.apache.commons.lang3.StringUtils;
+
+import java.util.HashSet;
+import java.util.Set;
+
+/**
+ * Case manipulation operations on Strings that contain words.
+ *
+ * This class tries to handle null input gracefully.
+ * An exception will not be thrown for a null input.
+ * Each method documents its behaviour in more detail.
+ *
+ * @since 1.0
+ */
+public class CaseUtils {
+
+/**
+ * CaseUtils instances should NOT be constructed in
+ * standard programming. Instead, the class should be used as
+ * CaseUtils.toCamelCase("foo bar", true, new 
char[]{'-'});.
+ * 
+ * This constructor is public to permit tools that require a 
JavaBean
+ * instance to operate.
+ */
+public CaseUtils() {
+super();
+}
+
+// Camel Case
+
//---
+/**
+ * Converts all the delimiter separated words in a String into 
camelCase,
+ * that is each word is made up of a titlecase character and then a 
series of
+ * lowercase characters. The  
+ *
+ * The delimiters represent a set of characters understood to 
separate words.
+ * The first non-delimiter character after a delimiter will be 
capitalized. The first String
+ * character may or may not be capitalized and it's determined by the 
user input for capitalizeFirstLetter
+ * variable.
+ *
+ * A null input String returns null.
+ * Capitalization uses the Unicode title case, normally equivalent to
+ * upper case.
+ *
+ * 
+ * CaseUtils.toCamelCase(null, false) 
= null
+ * CaseUtils.toCamelCase("", false, *)
= ""
+ * CaseUtils.toCamelCase(*, false, null)  
= *
+ * CaseUtils.toCamelCase(*, true, new char[0])
= *
+ * CaseUtils.toCamelCase("To.Camel.Case", false, new char[]{'.'}) 
= "toCamelCase"
+ * CaseUtils.toCamelCase(" to @ Camel case", true, new char[]{'@'})   
= "toCamelCase"
--- End diff --

Wouldn't we want
```java
CaseUtils.toCamelCase(" to @ Camel case", true, new char[]{'@'})   = 
"ToCamelCase"
```
because of the `true` boolean?


> Create CaseUtils class. Add toCamelCase
> ---
>
> Key: TEXT-85
> URL: https://issues.apache.org/jira/browse/TEXT-85
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>
> Based on the conversation here:
> http://markmail.org/message/7nvizsbykvxpr7g5
> We wish to have a {{toCamelCase}} method. The suggestion is to create a 
> {{CaseUtils}} class.
> I wonder if we should think about deprecating the case management in 
> {{WordUtils}} and move it over? Maybe, maybe not.
> I would think our method signature would look something like:
> {code}
> String toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)
> {code}
> potentially with {{String}} replaced with {{CharSequence}}.
> Lastly, {{WordUtils.capitalizeFully(String str, final char... delimiters)}} 
> might be a good starting point. 
> https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/WordUtils.java#L467-L499



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-85) Create CaseUtils class. Add toCamelCase

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046518#comment-16046518
 ] 

ASF GitHub Bot commented on TEXT-85:


Github user chtompki commented on a diff in the pull request:

https://github.com/apache/commons-text/pull/46#discussion_r121376091
  
--- Diff: src/main/java/org/apache/commons/text/CaseUtils.java ---
@@ -0,0 +1,140 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.text;
+
+import org.apache.commons.lang3.StringUtils;
+
+import java.util.HashSet;
+import java.util.Set;
+
+/**
+ * Case manipulation operations on Strings that contain words.
+ *
+ * This class tries to handle null input gracefully.
+ * An exception will not be thrown for a null input.
+ * Each method documents its behaviour in more detail.
+ *
+ * @since 1.0
+ */
+public class CaseUtils {
+
+/**
+ * CaseUtils instances should NOT be constructed in
+ * standard programming. Instead, the class should be used as
+ * CaseUtils.toCamelCase("foo bar", true, new 
char[]{'-'});.
+ * 
+ * This constructor is public to permit tools that require a 
JavaBean
+ * instance to operate.
+ */
+public CaseUtils() {
+super();
+}
+
+// Camel Case
+
//---
+/**
+ * Converts all the delimiter separated words in a String into 
camelCase,
+ * that is each word is made up of a titlecase character and then a 
series of
+ * lowercase characters. The  
+ *
+ * The delimiters represent a set of characters understood to 
separate words.
+ * The first non-delimiter character after a delimiter will be 
capitalized. The first String
+ * character may or may not be capitalized and it's determined by the 
user input for capitalizeFirstLetter
+ * variable.
+ *
+ * A null input String returns null.
+ * Capitalization uses the Unicode title case, normally equivalent to
+ * upper case.
+ *
+ * 
+ * CaseUtils.toCamelCase(null, false) 
= null
+ * CaseUtils.toCamelCase("", false, *)
= ""
+ * CaseUtils.toCamelCase(*, false, null)  
= *
+ * CaseUtils.toCamelCase(*, true, new char[0])
= *
+ * CaseUtils.toCamelCase("To.Camel.Case", false, new char[]{'.'}) 
= "toCamelCase"
+ * CaseUtils.toCamelCase(" to @ Camel case", true, new char[]{'@'})   
= "toCamelCase"
+ * CaseUtils.toCamelCase(" @to @ Camel case", false, new char[]{'@'}) 
= "toCamelCase"
+ * 
+ *
+ * @param str  the String to be converted to camelCase, may be null
+ * @param capitalizeFirstLetter boolean that determines if the first 
character of first word should be title case.
+ * @param delimiters  set of characters to determine capitalization, 
null and/or empty array means whitespace
+ * @return camelCase of String, null if null String input
+ */
+public static String toCamelCase(String str, boolean 
capitalizeFirstLetter, final char... delimiters) {
+if (StringUtils.isEmpty(str)) {
+return str;
+}
+str = str.toLowerCase();
+int strLen = str.length();
+int [] newCodePoints = new int[strLen];
+int outOffset = 0;
+Set delimiterSet = generateDelimiterSet(delimiters);
+boolean capitalizeNext = false;
+if (capitalizeFirstLetter) {
+capitalizeNext = true;
+}
+for (int index = 0; index < strLen;) {
+final int codePoint = str.codePointAt(index);
+
+if (delimiterSet.contains(codePoint)) {
+capitalizeNext = true;
+

[jira] [Commented] (TEXT-85) Create CaseUtils class. Add toCamelCase

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046519#comment-16046519
 ] 

ASF GitHub Bot commented on TEXT-85:


Github user chtompki commented on a diff in the pull request:

https://github.com/apache/commons-text/pull/46#discussion_r121378617
  
--- Diff: src/main/java/org/apache/commons/text/CaseUtils.java ---
@@ -0,0 +1,140 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.text;
+
+import org.apache.commons.lang3.StringUtils;
+
+import java.util.HashSet;
+import java.util.Set;
+
+/**
+ * Case manipulation operations on Strings that contain words.
+ *
+ * This class tries to handle null input gracefully.
+ * An exception will not be thrown for a null input.
+ * Each method documents its behaviour in more detail.
+ *
+ * @since 1.0
+ */
+public class CaseUtils {
+
+/**
+ * CaseUtils instances should NOT be constructed in
+ * standard programming. Instead, the class should be used as
+ * CaseUtils.toCamelCase("foo bar", true, new 
char[]{'-'});.
+ * 
+ * This constructor is public to permit tools that require a 
JavaBean
+ * instance to operate.
+ */
+public CaseUtils() {
+super();
+}
+
+// Camel Case
+
//---
+/**
+ * Converts all the delimiter separated words in a String into 
camelCase,
+ * that is each word is made up of a titlecase character and then a 
series of
+ * lowercase characters. The  
+ *
+ * The delimiters represent a set of characters understood to 
separate words.
+ * The first non-delimiter character after a delimiter will be 
capitalized. The first String
+ * character may or may not be capitalized and it's determined by the 
user input for capitalizeFirstLetter
+ * variable.
+ *
+ * A null input String returns null.
+ * Capitalization uses the Unicode title case, normally equivalent to
+ * upper case.
+ *
+ * 
+ * CaseUtils.toCamelCase(null, false) 
= null
+ * CaseUtils.toCamelCase("", false, *)
= ""
+ * CaseUtils.toCamelCase(*, false, null)  
= *
+ * CaseUtils.toCamelCase(*, true, new char[0])
= *
+ * CaseUtils.toCamelCase("To.Camel.Case", false, new char[]{'.'}) 
= "toCamelCase"
+ * CaseUtils.toCamelCase(" to @ Camel case", true, new char[]{'@'})   
= "toCamelCase"
+ * CaseUtils.toCamelCase(" @to @ Camel case", false, new char[]{'@'}) 
= "toCamelCase"
+ * 
+ *
+ * @param str  the String to be converted to camelCase, may be null
+ * @param capitalizeFirstLetter boolean that determines if the first 
character of first word should be title case.
+ * @param delimiters  set of characters to determine capitalization, 
null and/or empty array means whitespace
+ * @return camelCase of String, null if null String input
+ */
+public static String toCamelCase(String str, boolean 
capitalizeFirstLetter, final char... delimiters) {
+if (StringUtils.isEmpty(str)) {
+return str;
+}
+str = str.toLowerCase();
+int strLen = str.length();
+int [] newCodePoints = new int[strLen];
+int outOffset = 0;
+Set delimiterSet = generateDelimiterSet(delimiters);
+boolean capitalizeNext = false;
+if (capitalizeFirstLetter) {
+capitalizeNext = true;
+}
+for (int index = 0; index < strLen;) {
+final int codePoint = str.codePointAt(index);
--- End diff --

If we decide to go with `CharSequence` here, this becomes a tougher move. 
We have to begin 

[jira] [Commented] (TEXT-85) Create CaseUtils class. Add toCamelCase

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046515#comment-16046515
 ] 

ASF GitHub Bot commented on TEXT-85:


Github user chtompki commented on a diff in the pull request:

https://github.com/apache/commons-text/pull/46#discussion_r121374329
  
--- Diff: src/main/java/org/apache/commons/text/CaseUtils.java ---
@@ -0,0 +1,140 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.text;
+
+import org.apache.commons.lang3.StringUtils;
+
+import java.util.HashSet;
+import java.util.Set;
+
+/**
+ * Case manipulation operations on Strings that contain words.
+ *
+ * This class tries to handle null input gracefully.
+ * An exception will not be thrown for a null input.
+ * Each method documents its behaviour in more detail.
+ *
+ * @since 1.0
+ */
+public class CaseUtils {
+
+/**
+ * CaseUtils instances should NOT be constructed in
+ * standard programming. Instead, the class should be used as
+ * CaseUtils.toCamelCase("foo bar", true, new 
char[]{'-'});.
+ * 
+ * This constructor is public to permit tools that require a 
JavaBean
+ * instance to operate.
+ */
+public CaseUtils() {
--- End diff --

You could make the constructor `private`, but I do like the consistency 
with 
[`org.apache.commons.lang3.StringUtils.java`](https://github.com/apache/commons-lang/blob/master/src/main/java/org/apache/commons/lang3/StringUtils.java#L176-L186)


> Create CaseUtils class. Add toCamelCase
> ---
>
> Key: TEXT-85
> URL: https://issues.apache.org/jira/browse/TEXT-85
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>
> Based on the conversation here:
> http://markmail.org/message/7nvizsbykvxpr7g5
> We wish to have a {{toCamelCase}} method. The suggestion is to create a 
> {{CaseUtils}} class.
> I wonder if we should think about deprecating the case management in 
> {{WordUtils}} and move it over? Maybe, maybe not.
> I would think our method signature would look something like:
> {code}
> String toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)
> {code}
> potentially with {{String}} replaced with {{CharSequence}}.
> Lastly, {{WordUtils.capitalizeFully(String str, final char... delimiters)}} 
> might be a good starting point. 
> https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/WordUtils.java#L467-L499



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (NUMBERS-43) Remove "round(float)" methods?

[Gilles (JIRA)]

Gilles created NUMBERS-43:
-

 Summary: Remove "round(float)" methods?
 Key: NUMBERS-43
 URL: https://issues.apache.org/jira/browse/NUMBERS-43
 Project: Commons Numbers
  Issue Type: Wish
Reporter: Gilles
 Fix For: 1.0


In class {{Precision}}, there are methods for rounding {{float}} values, e.g.
{code:java}
public static float round(float x, int scale, int roundingMethod) { /* ... */ }
{code}

Is there any use for supporting specific handling of floats (in these times 
where memory is not a scarce resources anymore)?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-83) Deprecate CsvTranslators from from commons text in favor of Commons CSV

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046470#comment-16046470
 ] 

ASF GitHub Bot commented on TEXT-83:


Github user asfgit closed the pull request at:

https://github.com/apache/commons-text/pull/42


> Deprecate CsvTranslators from from commons text in favor of Commons CSV
> ---
>
> Key: TEXT-83
> URL: https://issues.apache.org/jira/browse/TEXT-83
> Project: Commons Text
>  Issue Type: Task
>Reporter: Amey Jadiye
>Priority: Minor
> Fix For: 1.x
>
>
> Deprecate CsvTranslators from from commons text in favor of Commons CSV



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (TEXT-67) NumericEntityUnescaper.options - TODO

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita resolved TEXT-67.

   Resolution: Fixed
Fix Version/s: (was: 1.x)
   1.2

> NumericEntityUnescaper.options - TODO
> -
>
> Key: TEXT-67
> URL: https://issues.apache.org/jira/browse/TEXT-67
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.0-beta-1
>Reporter: Rob Tompkins
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.2
>
>
> To mitigate having checkstyle errors, we have added this Jira en lieu of the 
> TODO comment in the code.
> Below the JavaDoc for the {{options}} private variable, but above the 
> variable reads:
> bq. Create an OptionsSet class to hide some of the conditional logic below



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-67) NumericEntityUnescaper.options - TODO

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046346#comment-16046346
 ] 

ASF GitHub Bot commented on TEXT-67:


Github user asfgit closed the pull request at:

https://github.com/apache/commons-text/pull/41


> NumericEntityUnescaper.options - TODO
> -
>
> Key: TEXT-67
> URL: https://issues.apache.org/jira/browse/TEXT-67
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.0-beta-1
>Reporter: Rob Tompkins
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.x
>
>
> To mitigate having checkstyle errors, we have added this Jira en lieu of the 
> TODO comment in the code.
> Below the JavaDoc for the {{options}} private variable, but above the 
> variable reads:
> bq. Create an OptionsSet class to hide some of the conditional logic below



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #268: .travis.yml: add oraclejdk9

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/268
  
Ooh, looked at the wrong green icon. JDK 7 complained about JAVA_HOME 
location... weird. Related issue in travis-ci repo 
https://github.com/travis-ci/travis-ci/issues/5520


---
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 issue #268: .travis.yml: add oraclejdk9

[britter]

Github user britter commented on the issue:

https://github.com/apache/commons-lang/pull/268
  
Travis build failed. Any idea why? Java 8 has an heap space error, while 
the Java 9 build reports an unrecognized VM option.


---
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 issue #268: .travis.yml: add oraclejdk9

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/268
  
+1 lgtm!


---
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.
---