Hi Gary, just to conclude the final action and clear midst here, I wish you
and team to elaborate your thought more on.
1. Deprecate CsvTranslator and point javadoc to use same methods present in
StringEscapeUtils in Commons Text.(moved from lang3)
2. Move CsvTranalator to Commons CSV all togethe
Hi All,
These talks are great; well done guys! I encourage all to watch :-)
Gary
On Sun, May 21, 2017 at 4:40 PM, Benedikt Ritter wrote:
> Hi,
>
> at this year’s ApacheCON we had some nice presentations. I’d like to share
> the video recordings with you (in order they were held at the event)
>
GitHub user jonasholtkamp opened a pull request:
https://github.com/apache/commons-collections/pull/22
[COLLECTIONS-600] Null-safe implementation of
CollectionUtils#isEqualCollection
Other Commons `*Utils` classes as `StringUtils` etc. feature null-safe
methods. With this Pull Requ
Mentioning the big picture again, Javadocs could also point to Commons CSV.
Gary
On May 25, 2017 12:06 PM, "Amey Jadiye" wrote:
> Agreed!, Thanks for sharing thoughts gary, now only marking CsvTranslator
> as deprecated will be OK.
>
> I'm marking methods from commons-text StringEscapeUtils as
Agreed!, Thanks for sharing thoughts gary, now only marking CsvTranslator
as deprecated will be OK.
I'm marking methods from commons-text StringEscapeUtils as alternative
to CsvTranslator,
Thanks.
Regards,
Amey
On Fri, May 26, 2017 at 12:25 AM, Gary Gregory
wrote:
> I think we need to step bac
I think we need to step back here, or up, and look at the big picture.
Commons CSV reads and writes CSV files. There a couple of additional cases
like writing CSV from JDBC result set.
The Commons Text CSV methods do low level work that is already done within
the guts of Commons CSV.
What is the
Hi Gary,
I have deprecated the CsvTranslator from commons text and was looking for
alternate API, we have it in StringEscapeUtils in commons text (and in
commons lang3 which is deprecated & which i'm not worry about), I think we
should remove those csv related methods from StringEscapeUtils as wel
On Thu, May 25, 2017 at 9:41 AM, Stephen Colebourne
wrote:
> On 25 May 2017 at 17:23, Oliver Heger
> wrote:
> > I also think that a new major release just to fix this problem would be
> > overkill and cause clients even more trouble.
> >
> > Would the following approach work as a compromise:
> >
On 25 May 2017 at 17:23, Oliver Heger wrote:
> I also think that a new major release just to fix this problem would be
> overkill and cause clients even more trouble.
>
> Would the following approach work as a compromise:
>
> - [lang] declares an optional dependency to the desktop module.
> - All
Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
> On 23 May 2017 at 17:17, sebb wrote:
>>> Yes, the
>>> code compiles and both can be on the classpath, but it is a pain to
>>> use, just a different kind of hell.
>>
>> I don't see what the problem is here.
>
> Library A that depends on lang3
> On 22 May 2017, at 12:15, Bruno P. Kinoshita
> wrote:
>
> I'd be in favour of 2 or some variation of it. Provide a well documented
> naïve implementation, and use whatever is available at the JVM for handling
> upper/lower case.
> I would use it for very simple cases, where all I need is to
Your point about BiFunction and BiPredicate is of course valid, but
there are a couple of things about those things that remediate their
awfulness.
1) They are interfaces, and thus describe function, not storage.
2) They are almost always transiently used, as anonymous/lamda classes,
and so
Am 25.05.2017 um 14:41 schrieb Rob Tompkins:
Fixed, but check behind me on that.
Works fine now. :=) Thank you very much!
Cheers,
Pascal
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-
> On May 25, 2017, at 8:32 AM, Rob Tompkins wrote:
>
>
>
>> On May 25, 2017, at 8:30 AM, Pascal Schumacher
>> wrote:
>>
>> Seems like something went wrong with the javadoc update:
>>
>> https://commons.apache.org/proper/commons-text/javadocs/api-release/
>>
>> "All Classes" displays the n
> On May 25, 2017, at 8:30 AM, Pascal Schumacher
> wrote:
>
> Seems like something went wrong with the javadoc update:
>
> https://commons.apache.org/proper/commons-text/javadocs/api-release/
>
> "All Classes" displays the new classes like WordUtils and
> RandomStringGenerator, but when I c
Seems like something went wrong with the javadoc update:
https://commons.apache.org/proper/commons-text/javadocs/api-release/
"All Classes" displays the new classes like WordUtils and
RandomStringGenerator, but when I click on the links I get:
"The requested URL
/proper/commons-text/javadocs
Am 24.05.2017 um 01:25 schrieb Benedikt Ritter:
I’m canceling this vote because:
- mvn site does not work from the src distribution
fixed:
https://github.com/apache/commons-lang/commit/670bb2e0a1e67894ac29bb1bc4287c40943f0205
---
On 25 May 2017 at 01:02, Gary Gregory wrote:
> On Wed, May 24, 2017 at 4:46 PM, Gary Gregory
> wrote:
>
>> On Wed, May 24, 2017 at 2:12 PM, Rob Tompkins wrote:
>>
>>>
>>> > On May 24, 2017, at 2:49 AM, Gary Gregory
>>> wrote:
>>> >
>>> > When I build with the IBM JDK 8 that IBM includes with so
> On May 25, 2017, at 6:31 AM, Pascal Schumacher
> wrote:
>
> Hi Rob,
>
> great news. :=)
>
> Thank you very much for being the release manager!
No worries. Thanks for helping with the code. :-)
-Rob
>
> Cheers,
> Pascal
>
>> Am 24.05.2017 um 16:47 schrieb Rob Tompkins:
>> The Apache
Hi Rob,
great news. :=)
Thank you very much for being the release manager!
Cheers,
Pascal
Am 24.05.2017 um 16:47 schrieb Rob Tompkins:
The Apache Commons Team is pleased to announce the release of
Apache Commons Text 1.1.
The Apache Commons Text open source software library provides a host o
20 matches
Mail list logo
