To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
Hi Sebb,
sebb wrote:
> On 8 April 2011 00:09, Jörg Schaible wrote:
[snip]
>> Since we have no consensus yet and in case someone else wants to get rid
>> of it, here is the bash command:
>>
>> == %<
>> $ cd lang
>> $ sed -i -s -e '\,/\*\*, {
>> N
>> /{@inheritDoc}/ {
>>
I'm +1 to keep @inheritDoc, for me it's like @Override
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Apr 8, 2011 at 1:58 AM, sebb wrote:
> On 8 April 2011 00:09, Jörg Schaible wrote:
>> Matt Benson wrote:
>>
>>> On Thu, Apr 7, 2011 at 5:02 PM, Konstantin Kolinko
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-scxml-test has an issue affecting its community integration.
This
On 8 April 2011 00:09, Jörg Schaible wrote:
> Matt Benson wrote:
>
>> On Thu, Apr 7, 2011 at 5:02 PM, Konstantin Kolinko
>> wrote:
>>> 2011/4/8 Jörg Schaible :
Hi,
just a reminder. Such a javadoc comment for a method is completely
superfluous:
%< ===
Matt Benson wrote:
> On Thu, Apr 7, 2011 at 5:02 PM, Konstantin Kolinko
> wrote:
>> 2011/4/8 Jörg Schaible :
>>> Hi,
>>>
>>> just a reminder. Such a javadoc comment for a method is completely
>>> superfluous:
>>>
>>> %< =
>>> /**
>>> * {@inheritDoc}
>>> */
>>> ===
On 7 April 2011 23:33, Matt Benson wrote:
>>> This is what the javadoc nowadays does by default ...
>>>
>>
>> Yes, but personally I like them as a good reminder when looking though the
>> code.
>> (Or as "nothing more to add").
>
> I feel more comfortable seeing them as well (I'm almost certainly
Hi Manuel,
I would suggest to set the dafult type to String beause thats exactly what i
was expacting. I would have provided a patch but i was not sure where to
implement it (either as a fallback in CommandLine.getParsedOptionValue or in
the Option constructor).
That's a good suggestion, coul
On Thu, Apr 7, 2011 at 5:02 PM, Konstantin Kolinko
wrote:
> 2011/4/8 Jörg Schaible :
>> Hi,
>>
>> just a reminder. Such a javadoc comment for a method is completely
>> superfluous:
>>
>> %< =
>> /**
>> * {@inheritDoc}
>> */
>> %< =
>>
>> This is
2011/4/8 Jörg Schaible :
> Hi,
>
> just a reminder. Such a javadoc comment for a method is completely
> superfluous:
>
> %< =
> /**
> * {@inheritDoc}
> */
> %< =
>
> This is what the javadoc nowadays does by default ...
>
Yes, but personally I li
On Mon, Mar 7, 2011 at 10:05 PM, Henri Yandell wrote:
> On Sat, Mar 5, 2011 at 8:46 AM, Oliver Heger
> wrote:
>> Two minor points from my side:
>>
>
>> - Just a proposal: There are some translators in the new translate package
>> which can be configured with a range of the codes to be processed.
Feel free to remove :) Looks like not much in there on the lang side.
On Thu, Apr 7, 2011 at 2:46 PM, Jörg Schaible wrote:
> Hi,
>
> just a reminder. Such a javadoc comment for a method is completely
> superfluous:
>
> %< =
> /**
> * {@inheritDoc}
> */
> %<
Hi,
just a reminder. Such a javadoc comment for a method is completely
superfluous:
%< =
/**
* {@inheritDoc}
*/
%< =
This is what the javadoc nowadays does by default ...
- Jörg
--
Hi all guys,
I don't want to hijack the thread but also Discovery was in "critical
care" but we gave it a new life, if it could help saving
commons-collections from the die I'm available to help (just the time
to release discovery)
Have a nice day!
Simo
http://people.apache.org/~simonetripodi/
htt
On 7 April 2011 21:55, Henri Yandell wrote:
> Scratch that - the build seemed to work again when I rolled back, but
> that was different code on my side failing and stopping the TypeUtils
> fail from happening.
>
> Rolling forward again :)
Sorry, I caused it - Eclipse reported an unnecessary cast
On Thu, Apr 7, 2011 at 1:57 PM, Phil Steitz wrote:
> On 4/7/11 1:14 PM, sebb wrote:
>> On 7 April 2011 21:08, Henri Yandell wrote:
>>> On Thu, Apr 7, 2011 at 10:48 AM, Phil Steitz wrote:
I think the idea of having a separate, releasable "child" of some
kind that can break compatibility
On 4/7/11 1:14 PM, sebb wrote:
> On 7 April 2011 21:08, Henri Yandell wrote:
>> On Thu, Apr 7, 2011 at 10:48 AM, Phil Steitz wrote:
>>> I think the idea of having a separate, releasable "child" of some
>>> kind that can break compatibility with its parent and earlier
>>> versions of itself is a g
Scratch that - the build seemed to work again when I rolled back, but
that was different code on my side failing and stopping the TypeUtils
fail from happening.
Rolling forward again :)
On Thu, Apr 7, 2011 at 1:49 PM, Henri Yandell wrote:
> Not sure why, but the TypeUtils change broke things. Ro
On Thu, Apr 7, 2011 at 3:49 PM, Henri Yandell wrote:
> Not sure why, but the TypeUtils change broke things. Rolling back for now.
>
I was thinking there was some reason for it.
Matt
> svn ci -m "Rolling back the TypeUtilsTest change in r1089973 as it
> breaks the build. Unsure why."
> src/test/
Not sure why, but the TypeUtils change broke things. Rolling back for now.
svn ci -m "Rolling back the TypeUtilsTest change in r1089973 as it
breaks the build. Unsure why."
src/test/java/org/apache/commons/lang3/reflect/TypeUtilsTest.java
Sendingsrc/test/java/org/apache/commons/lang3/refle
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=6999&projectId=95
Build statistics:
State: Failed
Previous State: Ok
Started at: Thu 7 Apr 2011 20:32:53 +
Finished at: Thu 7 Apr 2011 20:33:24 +
Total time: 30s
Build Trigger: Schedule
Build Numb
On 7 April 2011 21:08, Henri Yandell wrote:
> On Thu, Apr 7, 2011 at 10:48 AM, Phil Steitz wrote:
>>
>> I think the idea of having a separate, releasable "child" of some
>> kind that can break compatibility with its parent and earlier
>> versions of itself is a good one. The setup I have describ
Hello,
yesterday i was doing some work with commons-cli and stumbled across
getParsedOptionValue in the CommandLine class.
Being new to this library i was very confused to always get a null value
instead of some string. The problem was that i didn't set the type in my
Option objects.
I would sugge
On Thu, Apr 7, 2011 at 10:48 AM, Phil Steitz wrote:
>
> I think the idea of having a separate, releasable "child" of some
> kind that can break compatibility with its parent and earlier
> versions of itself is a good one. The setup I have described above
> is probably not the best, but we should
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-id has an issue affecting its community integration.
This issue af
Am 07.04.2011 11:35, schrieb Delepine Ghislain (ALTEN):
Hi,
Could anyone please explain why empty XML attributes are removed in
XMLConfiguration ?
(method XMLConfiguration$XMLBuilderVisitor.updateAttribute(Node node,
Element elem, String name, char listDelimiter))
As discussed in the follo
On 4/7/11 10:00 AM, sebb wrote:
> On 7 April 2011 16:42, Henri Yandell wrote:
>> On Thu, Apr 7, 2011 at 8:32 AM, Jochen Wiedmann
>> wrote:
>>> On Thu, Apr 7, 2011 at 5:28 PM, Henri Yandell wrote:
>>>
I think a separate jar would be lot less valuable - that basically
makes it a separate
On 7 April 2011 16:42, Henri Yandell wrote:
> On Thu, Apr 7, 2011 at 8:32 AM, Jochen Wiedmann
> wrote:
>> On Thu, Apr 7, 2011 at 5:28 PM, Henri Yandell wrote:
>>
>>> I think a separate jar would be lot less valuable - that basically
>>> makes it a separate project/branch etc. Even if we mess aro
On Thu, Apr 7, 2011 at 8:32 AM, Jochen Wiedmann
wrote:
> On Thu, Apr 7, 2011 at 5:28 PM, Henri Yandell wrote:
>
>> I think a separate jar would be lot less valuable - that basically
>> makes it a separate project/branch etc. Even if we mess around in
>> Maven to produce multiple jars, we're still
It's worthless unless we release it. :(
A similar example is that I don't see why we can't have lang4 code
appearing in the lang3 jar; and I don't see why we would have to be
backwards compat for the lang4 code while on the lang3 branch.
I agree it's novel, but lang is too core to other projects
Looks fun. I've not used Google Collections much; but equally I don't
use Commons Collections much either :)
Generally I've seen Guava as akin to Joda Time; it's a better JDK
[obviously for a value of better; but I've liked a lot of what I've
seen]. Lang is generally just trying to put simple patc
I'd agree with an alpha area, but I don't agree with releasing it.
[lang] is too core to other projects to be doing things like that IMO.
Stephen
On 7 April 2011 07:35, Henri Yandell wrote:
> I've been pondering the tension between stability and innovation.
>
> Once 3.0 is out I'd like to add a
On Thu, Apr 7, 2011 at 5:28 PM, Henri Yandell wrote:
> I think a separate jar would be lot less valuable - that basically
> makes it a separate project/branch etc. Even if we mess around in
> Maven to produce multiple jars, we're still create two separate
> artifacts simply to deal with any tooli
Sounds very reasonable, thanks for watching and commenting :)
Doing the performance check would be valuable (to know the magnitude),
but I agree that the green method shouldn't beat toString().
Hen
On Thu, Apr 7, 2011 at 2:49 AM, Julien Aymé wrote:
> Hi,
>
> I think that for char[] based implem
On Thu, Apr 7, 2011 at 4:40 AM, sebb wrote:
> On 7 April 2011 05:34, wrote:
>> Author: bayard
>> Date: Thu Apr 7 04:34:35 2011
>> New Revision: 1089733
>>
>> URL: http://svn.apache.org/viewvc?rev=1089733&view=rev
>> Log:
>> Reapplying more of Oliver's checkstyle fixes from r1083211
>>
>> Modifi
On Thu, Apr 7, 2011 at 4:07 AM, sebb wrote:
> On 7 April 2011 07:35, Henri Yandell wrote:
>> I've been pondering the tension between stability and innovation.
>>
>> Once 3.0 is out I'd like to add an alpha subpackage:
>>
>> org.apache.commons.lang-alpha
>>
>> It's specifically a location of code
On Thu, Apr 7, 2011 at 1:52 AM, James Ring wrote:
> Have you seen
> http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Ordering.html
> ? This does similar stuff to ReverseComparator and the API is
> excellent.
>
> On Thu, Apr 7, 2011 at 4:37 PM, Henri Yandell wr
On Apr 7, 2011, at 2:36, Henri Yandell wrote:
> I've been pondering the tension between stability and innovation.
>
> Once 3.0 is out I'd like to add an alpha subpackage:
>
> org.apache.commons.lang-alpha
>
> It's specifically a location of code that is:
>
> a) Not linked to a version. When we
On Apr 7, 2011, at 2:29, Henri Yandell wrote:
> StringUtils is ready now I believe.
>
> The 7 methods on the end have now been moved to the resurrected
> CharSequenceUtils class. It only has 1 public class, but I think the
> other methods can be added over time. Not something to block 3.0 on,
> b
On 7 April 2011 05:34, wrote:
> Author: bayard
> Date: Thu Apr 7 04:34:35 2011
> New Revision: 1089733
>
> URL: http://svn.apache.org/viewvc?rev=1089733&view=rev
> Log:
> Reapplying more of Oliver's checkstyle fixes from r1083211
>
> Modified:
>
> commons/proper/lang/trunk/src/main/java/org/
On 7 April 2011 07:35, Henri Yandell wrote:
> I've been pondering the tension between stability and innovation.
>
> Once 3.0 is out I'd like to add an alpha subpackage:
>
> org.apache.commons.lang-alpha
>
> It's specifically a location of code that is:
>
> a) Not linked to a version. When we mov
Hi,
I think that for char[] based implementation of CharSequence (mainly
StringBuffer/StringBuilder),
it would be faster to convert to String (copy char[] once) then invoke
to charArray method (copy char[] twice).
Indeed, invoking many times charAt(index) may be costly since the
range check would
- "Henri Yandell" a écrit :
> I've been pondering the tension between stability and innovation.
>
> Once 3.0 is out I'd like to add an alpha subpackage:
>
> org.apache.commons.lang-alpha
>
> It's specifically a location of code that is:
>
> a) Not linked to a version. When we move to
43 matches
Mail list logo
