> 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 w
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
> .gitigno
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
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 simi
+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 Tompkin
> 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_NAM
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 dyn
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 conv
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
> 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.
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 ca
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
-
> 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&commentId=16031153
>
> To address https://issues.apache.org/jira/browse/FILEUPLOAD-279
>
> Is anyone will
13 matches
Mail list logo
