Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

2017-06-01 Thread Rob Tompkins


> On Jun 1, 2017, at 11:38 AM, Duncan Jones  wrote:
> 
>> On Thu, 1 Jun 2017 at 16:31, Amey Jadiye  wrote:
>> 
>> +1 seems good to have in toolbox. pretty similar method I have seen in
>> Commons text WordUtils.capitalize() almost similar logic we will need here
>> ,just not to capitalize first word and join them all, I'm in favour of
>> having this in WordUtils.
> 
> 
> We've discussed deprecating WorldUtils once the wrapping methods are broken
> out into separate classes. I'm in favour of an individual class to do this
> work.

Sure. Seems reasonable.

> 
> 
>> 
>> Regards,
>> Amey
>> 
>>> On Thu, Jun 1, 2017, 7:33 PM Rob Tompkins  wrote:
>>> 
>>> Hello all,
>>> 
>>> Folks at my day job have a method that takes in a space delimited String
>>> (or arbitrarily delimited string for that matter), and returns a camel
>>> cased string. Is there any reason that this shouldn’t be in StringUtils?
>> It
>>> feels reasonable to me. What are folks thoughts?
>>> 
>>> Cheers,
>>> -Rob
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [all] Should our gitignore files contain only build-related entries?

2017-06-01 Thread Gary Gregory
If we do not have per component .gitignore files, then we better have clear
instructions front and center on how to set up Git for what we expect.

Gary

On Wed, May 31, 2017 at 2:04 AM, Amey Jadiye  wrote:

> Hi,
>
> I think easier way to have all ignorable extensions and directories in
> .gitignore and same have to be replicated in global gitignore from all
> other Commons projects. Commons is always having short fixes and
> improvements , people tend to fork>work>PR>delete repo on local pc.
> Instructions should be in UsingGIT and CONTRIBUTING.md but not sure people
> will follow everything. Ignores already  present in .gitignore of each
> project makes everything painles.
>
> Regards,
> Amey
>
> On Sat, May 27, 2017, 7:03 PM Bruno P. Kinoshita
>  wrote:
>
> > Hi,
> >
> > [collections] recently received a pull request [1] to add VIM files to
> the
> > gitignore file. Its currently gitignore contains only a few entries for
> > Eclipse ([lang] has more entries for Eclipse).
> >
> > I remember asking something similar, and learning about the global
> > gitignore. But besides that, in the same thread, Benedikt suggested
> having
> > only build files ignored in our gitignore files [2], which I think is a
> > good idea. Our components do not follow any rule for gitignore files I
> > think. I normally check [lang] when I need to add a .gitignore to a new
> > computer, but just realized [text] and [lang] gitignore files differ
> > ([lang] has a .checkstyle file under the Eclipse ignored files).
> >
> >
> > I'm okay merging the pull request for [collections], but then we may also
> > add the remaining entries from [lang] there... except this pull request
> > adds *.swp which is missing from [lang]. So should we add it there too?
> >
> > Some days ago I used NetBeans to test a generics suppress warning message
> > [3], but we may have developers using it as main IDE too. Would it be all
> > right to merge pull requests for it too? Or for files generated by
> plug-ins
> > for Eclipse/IntelliJ/etc?
> > What about 1) leaving only files generated by our build tools, 2) add a
> > comment to the .gitignore file describing how it works with links, 3)
> add a
> > comment to
> > https://wiki.apache.org/commons/UsingGIT and/or to the CONTRIBUTING.md
> > perhaps with a sample global gitignore file?
> >
> > Cheers
> > Bruno
> >
> > [1] https://github.com/apache/commons-collections/pull/21
> > [2]
> > http://markmail.org/message/yvflc6kxgjalhldx?q=global+
> gitignore+list:org%2Eapache%2Ecommons%2Edev#query:global%
> 20gitignore%20list%3Aorg.apache.commons.dev+page:1+mid:
> ioex63sxnf6culwb+state:results
> > [3] https://github.com/apache/commons-collections/pull/17
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>


Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

2017-06-01 Thread Duncan Jones
On Thu, 1 Jun 2017 at 16:31, Amey Jadiye  wrote:

> +1 seems good to have in toolbox. pretty similar method I have seen in
> Commons text WordUtils.capitalize() almost similar logic we will need here
> ,just not to capitalize first word and join them all, I'm in favour of
> having this in WordUtils.


We've discussed deprecating WorldUtils once the wrapping methods are broken
out into separate classes. I'm in favour of an individual class to do this
work.


>
> Regards,
> Amey
>
> On Thu, Jun 1, 2017, 7:33 PM Rob Tompkins  wrote:
>
> > Hello all,
> >
> > Folks at my day job have a method that takes in a space delimited String
> > (or arbitrarily delimited string for that matter), and returns a camel
> > cased string. Is there any reason that this shouldn’t be in StringUtils?
> It
> > feels reasonable to me. What are folks thoughts?
> >
> > Cheers,
> > -Rob
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>


Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

2017-06-01 Thread Matt Sicker
I like the idea. I've written similar code in a log4j2 branch for
normalizing configuration property names into camel case names.

On 1 June 2017 at 10:31, Amey Jadiye  wrote:

> +1 seems good to have in toolbox. pretty similar method I have seen in
> Commons text WordUtils.capitalize() almost similar logic we will need here
> ,just not to capitalize first word and join them all, I'm in favour of
> having this in WordUtils.
>
> Regards,
> Amey
>
> On Thu, Jun 1, 2017, 7:33 PM Rob Tompkins  wrote:
>
> > Hello all,
> >
> > Folks at my day job have a method that takes in a space delimited String
> > (or arbitrarily delimited string for that matter), and returns a camel
> > cased string. Is there any reason that this shouldn’t be in StringUtils?
> It
> > feels reasonable to me. What are folks thoughts?
> >
> > Cheers,
> > -Rob
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>



-- 
Matt Sicker 


Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

2017-06-01 Thread Amey Jadiye
+1 seems good to have in toolbox. pretty similar method I have seen in
Commons text WordUtils.capitalize() almost similar logic we will need here
,just not to capitalize first word and join them all, I'm in favour of
having this in WordUtils.

Regards,
Amey

On Thu, Jun 1, 2017, 7:33 PM Rob Tompkins  wrote:

> Hello all,
>
> Folks at my day job have a method that takes in a space delimited String
> (or arbitrarily delimited string for that matter), and returns a camel
> cased string. Is there any reason that this shouldn’t be in StringUtils? It
> feels reasonable to me. What are folks thoughts?
>
> Cheers,
> -Rob
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

2017-06-01 Thread Rob Tompkins

> On Jun 1, 2017, at 10:58 AM, Roger Whitcomb  wrote:
> 
> I have a similar method in our code -- the use case is to take user input 
> (plain English field names, for instance) and turn it into variable names for 
> DTOs (or similar).
> 
> Another use we have for it is taking Java format ENUM_NAMES and turning them 
> into camelCaseVariableNames for things like dynamic property sheets.

This is quite similar to what we are doing as well.

and @Gary - I like both ideas, WordUtils or CamelCaseUtils.

-Rob

> 
> ~Roger Whitcomb
> 
> -Original Message-
> From: Duncan Jones [mailto:dun...@wortharead.com] 
> Sent: Thursday, June 01, 2017 7:32 AM
> To: Commons Developers List 
> Subject: Re: [lang] Appetite for new method StringUtils.toCamelCase(String 
> str, char delimiter, boolean capitalizeFirstLetter)
> 
> On Thu, 1 Jun 2017 at 15:27, Gary Gregory  wrote:
> 
>> IMO camel casing is all about words so [text] WordUtils. But why not 
>> have a CamelCaseUtils instead?
>> 
>> Gary
> 
> 
> +1. IMO it belongs in TEXT (if anywhere) and we should avoid classes 
> +with
> static methods.
> 
> Per our other conservation about case conversions, we should carefully 
> specify whether this uses upper- or title-case and how it behaves in 
> different locales.
> 
> OOI, what is your real world use case for this?
> 
> Duncan
> 
> 
>> 
>> On Jun 1, 2017 7:14 AM, "Rob Tompkins"  wrote:
>> 
>>> 
 On Jun 1, 2017, at 10:11 AM, Gary Gregory 
>>> wrote:
 
 Isn't this kind of stuff or anything camel case supposed to be in
>> [text]
>>> 
>>> I’m ok with that path as well. It feels like it’s on the line 
>>> between the two components. Either way, it sounds like you’re not 
>>> opposed to adding
>> it
>>> to a component.
>>> 
>>> Should it be TextUtils.toCamelCase(String str, char delimiter, 
>>> boolean capitalizeFirstLetter), or WordUtils maybe, if we were to 
>>> put it in
>> [text]?
>>> 
>>> -Rob
>>> 
 these days?
 
 Gary
 
 On Jun 1, 2017 7:03 AM, "Rob Tompkins"  wrote:
 
> Hello all,
> 
> Folks at my day job have a method that takes in a space delimited
>> String
> (or arbitrarily delimited string for that matter), and returns a 
> camel cased string. Is there any reason that this shouldn’t be in
>>> StringUtils? It
> feels reasonable to me. What are folks thoughts?
> 
> Cheers,
> -Rob
> -
>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
>>> 
>>> 
>>> 
>>> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



RE: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

2017-06-01 Thread Roger Whitcomb
I have a similar method in our code -- the use case is to take user input 
(plain English field names, for instance) and turn it into variable names for 
DTOs (or similar).

Another use we have for it is taking Java format ENUM_NAMES and turning them 
into camelCaseVariableNames for things like dynamic property sheets.

~Roger Whitcomb

-Original Message-
From: Duncan Jones [mailto:dun...@wortharead.com] 
Sent: Thursday, June 01, 2017 7:32 AM
To: Commons Developers List 
Subject: Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, 
char delimiter, boolean capitalizeFirstLetter)

On Thu, 1 Jun 2017 at 15:27, Gary Gregory  wrote:

> IMO camel casing is all about words so [text] WordUtils. But why not 
> have a CamelCaseUtils instead?
>
> Gary


+1. IMO it belongs in TEXT (if anywhere) and we should avoid classes 
+with
static methods.

Per our other conservation about case conversions, we should carefully specify 
whether this uses upper- or title-case and how it behaves in different locales.

OOI, what is your real world use case for this?

Duncan


>
> On Jun 1, 2017 7:14 AM, "Rob Tompkins"  wrote:
>
> >
> > > On Jun 1, 2017, at 10:11 AM, Gary Gregory 
> > wrote:
> > >
> > > Isn't this kind of stuff or anything camel case supposed to be in
> [text]
> >
> > I’m ok with that path as well. It feels like it’s on the line 
> > between the two components. Either way, it sounds like you’re not 
> > opposed to adding
> it
> > to a component.
> >
> > Should it be TextUtils.toCamelCase(String str, char delimiter, 
> > boolean capitalizeFirstLetter), or WordUtils maybe, if we were to 
> > put it in
> [text]?
> >
> > -Rob
> >
> > > these days?
> > >
> > > Gary
> > >
> > > On Jun 1, 2017 7:03 AM, "Rob Tompkins"  wrote:
> > >
> > >> Hello all,
> > >>
> > >> Folks at my day job have a method that takes in a space delimited
> String
> > >> (or arbitrarily delimited string for that matter), and returns a 
> > >> camel cased string. Is there any reason that this shouldn’t be in
> > StringUtils? It
> > >> feels reasonable to me. What are folks thoughts?
> > >>
> > >> Cheers,
> > >> -Rob
> > >> -
> > >>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > >>
> > >>
> >
> >
> > 
> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

2017-06-01 Thread Duncan Jones
On Thu, 1 Jun 2017 at 15:27, Gary Gregory  wrote:

> IMO camel casing is all about words so [text] WordUtils. But why not have a
> CamelCaseUtils instead?
>
> Gary


+1. IMO it belongs in TEXT (if anywhere) and we should avoid classes with
static methods.

Per our other conservation about case conversions, we should carefully
specify whether this uses upper- or title-case and how it behaves in
different locales.

OOI, what is your real world use case for this?

Duncan


>
> On Jun 1, 2017 7:14 AM, "Rob Tompkins"  wrote:
>
> >
> > > On Jun 1, 2017, at 10:11 AM, Gary Gregory 
> > wrote:
> > >
> > > Isn't this kind of stuff or anything camel case supposed to be in
> [text]
> >
> > I’m ok with that path as well. It feels like it’s on the line between the
> > two components. Either way, it sounds like you’re not opposed to adding
> it
> > to a component.
> >
> > Should it be TextUtils.toCamelCase(String str, char delimiter, boolean
> > capitalizeFirstLetter), or WordUtils maybe, if we were to put it in
> [text]?
> >
> > -Rob
> >
> > > these days?
> > >
> > > Gary
> > >
> > > On Jun 1, 2017 7:03 AM, "Rob Tompkins"  wrote:
> > >
> > >> Hello all,
> > >>
> > >> Folks at my day job have a method that takes in a space delimited
> String
> > >> (or arbitrarily delimited string for that matter), and returns a camel
> > >> cased string. Is there any reason that this shouldn’t be in
> > StringUtils? It
> > >> feels reasonable to me. What are folks thoughts?
> > >>
> > >> Cheers,
> > >> -Rob
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > >>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>


Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

2017-06-01 Thread Gary Gregory
IMO camel casing is all about words so [text] WordUtils. But why not have a
CamelCaseUtils instead?

Gary

On Jun 1, 2017 7:14 AM, "Rob Tompkins"  wrote:

>
> > On Jun 1, 2017, at 10:11 AM, Gary Gregory 
> wrote:
> >
> > Isn't this kind of stuff or anything camel case supposed to be in [text]
>
> I’m ok with that path as well. It feels like it’s on the line between the
> two components. Either way, it sounds like you’re not opposed to adding it
> to a component.
>
> Should it be TextUtils.toCamelCase(String str, char delimiter, boolean
> capitalizeFirstLetter), or WordUtils maybe, if we were to put it in [text]?
>
> -Rob
>
> > these days?
> >
> > Gary
> >
> > On Jun 1, 2017 7:03 AM, "Rob Tompkins"  wrote:
> >
> >> Hello all,
> >>
> >> Folks at my day job have a method that takes in a space delimited String
> >> (or arbitrarily delimited string for that matter), and returns a camel
> >> cased string. Is there any reason that this shouldn’t be in
> StringUtils? It
> >> feels reasonable to me. What are folks thoughts?
> >>
> >> Cheers,
> >> -Rob
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

2017-06-01 Thread Rob Tompkins

> On Jun 1, 2017, at 10:11 AM, Gary Gregory  wrote:
> 
> Isn't this kind of stuff or anything camel case supposed to be in [text]

I’m ok with that path as well. It feels like it’s on the line between the two 
components. Either way, it sounds like you’re not opposed to adding it to a 
component.

Should it be TextUtils.toCamelCase(String str, char delimiter, boolean 
capitalizeFirstLetter), or WordUtils maybe, if we were to put it in [text]?

-Rob

> these days?
> 
> Gary
> 
> On Jun 1, 2017 7:03 AM, "Rob Tompkins"  wrote:
> 
>> Hello all,
>> 
>> Folks at my day job have a method that takes in a space delimited String
>> (or arbitrarily delimited string for that matter), and returns a camel
>> cased string. Is there any reason that this shouldn’t be in StringUtils? It
>> feels reasonable to me. What are folks thoughts?
>> 
>> Cheers,
>> -Rob
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

2017-06-01 Thread Gary Gregory
Isn't this kind of stuff or anything camel case supposed to be in [text]
these days?

Gary

On Jun 1, 2017 7:03 AM, "Rob Tompkins"  wrote:

> Hello all,
>
> Folks at my day job have a method that takes in a space delimited String
> (or arbitrarily delimited string for that matter), and returns a camel
> cased string. Is there any reason that this shouldn’t be in StringUtils? It
> feels reasonable to me. What are folks thoughts?
>
> Cheers,
> -Rob
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


[lang] Appetite for new method StringUtils.toCamelCase(String str, char delimiter, boolean capitalizeFirstLetter)

2017-06-01 Thread Rob Tompkins
Hello all,

Folks at my day job have a method that takes in a space delimited String (or 
arbitrarily delimited string for that matter), and returns a camel cased 
string. Is there any reason that this shouldn’t be in StringUtils? It feels 
reasonable to me. What are folks thoughts?

Cheers,
-Rob
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [FileUpload] Release FILEUPLOAD-279

2017-06-01 Thread Rob Tompkins

> On May 31, 2017, at 5:42 PM, Gary Gregory  wrote:
> 
> Hi All:
> 
> We have a request to release FileUpload;
> 
> https://issues.apache.org/jira/secure/EditComment!default.jspa?id=13020471=16031153
> 
> To address https://issues.apache.org/jira/browse/FILEUPLOAD-279
> 
> Is anyone willing to RM?

I can try to get to it between now and Monday.

> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> 
> 
> JUnit in Action, Second Edition
> 
> 
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org