> 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
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
-
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
> 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.
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 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
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 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
+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
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
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
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 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
13 matches
Mail list logo
