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
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=7208&projectId=65
Build statistics:
State: Failed
Previous State: Failed
Started at: Tue 12 Apr 2011 05:48:47 +
Finished at: Tue 12 Apr 2011 05:50:21 +
Total time: 1m 33s
Build Trigger: Schedule
B
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 Mon, Apr 11, 2011 at 8:00 PM, sebb wrote:
> On 9 April 2011 04:00, Gary Gregory wrote:
> > On Apr 8, 2011, at 21:51, sebb wrote:
> >
> >> On 9 April 2011 01:21, Gary Gregory wrote:
> >>> Can we add a test jar to the list please? The apache release profile
> >>> should take care of it but I
On 9 April 2011 04:00, Gary Gregory wrote:
> On Apr 8, 2011, at 21:51, sebb wrote:
>
>> On 9 April 2011 01:21, Gary Gregory wrote:
>>> Can we add a test jar to the list please? The apache release profile
>>> should take care of it but I want to mention it here explicitly.
I assume you want the
On Mon, Apr 11, 2011 at 06:02:52PM -, l...@apache.org wrote:
> Author: luc
> Date: Mon Apr 11 18:02:52 2011
> New Revision: 1091153
>
> URL: http://svn.apache.org/viewvc?rev=1091153&view=rev
> Log:
> make sure the test runs correctly even in a non-US environment
>
> Modified:
>
> commons
On Mon, Apr 11, 2011 at 3:43 PM, Gary Gregory wrote:
> On Mon, Apr 11, 2011 at 4:26 PM, Henri Yandell wrote:
>>
>> +1 to rename getShortClassName to getSimpleName; sitting on top of the
>> JDK getSimpleName and providing null safety and whatever other
>> features are needed (for example array enc
On Mon, Apr 11, 2011 at 4:26 PM, Henri Yandell wrote:
> +1 to rename getShortClassName to getSimpleName; sitting on top of the
> JDK getSimpleName and providing null safety and whatever other
> features are needed (for example array encoding).
>
You must mean deprecate getShortClassName (to remo
On Mon, Apr 11, 2011 at 6:36 PM, Gary Gregory wrote:
> On Mon, Apr 11, 2011 at 4:25 PM, Matt Benson wrote:
>
>> On Mon, Apr 11, 2011 at 1:17 PM, Gary Gregory
>> wrote:
>> > On Mon, Apr 11, 2011 at 2:14 PM, Gary Gregory > >wrote:
>> >
>> >> On Mon, Apr 11, 2011 at 1:52 PM, Stephen Colebourne <
>>
On Mon, Apr 11, 2011 at 4:25 PM, Matt Benson wrote:
> On Mon, Apr 11, 2011 at 1:17 PM, Gary Gregory
> wrote:
> > On Mon, Apr 11, 2011 at 2:14 PM, Gary Gregory >wrote:
> >
> >> On Mon, Apr 11, 2011 at 1:52 PM, Stephen Colebourne <
> scolebou...@joda.org>wrote:
> >>
> >>> I fixed the Map.Entry eq
On Sat, Apr 9, 2011 at 4:15 AM, sebb wrote:
> On 9 April 2011 06:06, Henri Yandell wrote:
>
> Release Notes link to a draft upgrade page.
> I would have preferred to see most of the details in the RN themselves.
> I expect to be able to download the archive and find the important
> information a
+1 to rename getShortClassName to getSimpleName; sitting on top of the
JDK getSimpleName and providing null safety and whatever other
features are needed (for example array encoding).
Hen
On Mon, Apr 11, 2011 at 7:18 AM, Gary Gregory wrote:
> Hi All:
>
> Should we deprecate ClassUtils getShortCl
On Mon, Apr 11, 2011 at 1:17 PM, Gary Gregory wrote:
> On Mon, Apr 11, 2011 at 2:14 PM, Gary Gregory wrote:
>
>> On Mon, Apr 11, 2011 at 1:52 PM, Stephen Colebourne
>> wrote:
>>
>>> I fixed the Map.Entry equals/hashCode compliance.
>>>
>>> I shortened the toString form to omit the class name, as
I'm all for moving to the Attic instead of a Commons Attic. Phil's
email makes me think that we have very little that would be up for the
Attic; but we do have some candidates and I'd like to see us clearly
defining the dead from the dormant. Also to drive us to think about
telling the dead from th
On Mon, Apr 11, 2011 at 8:03 AM, Matt Benson wrote:
> On Mon, Apr 11, 2011 at 9:23 AM, Matt Benson wrote:
>> On Sun, Apr 10, 2011 at 10:51 PM, Matt Benson wrote:
>>> On Sun, Apr 10, 2011 at 7:17 PM, Henri Yandell wrote:
On Sun, Apr 10, 2011 at 1:43 PM, Phil Steitz wrote:
> -0
>
>>
On Mon, Apr 11, 2011 at 7:23 AM, Matt Benson wrote:
>
> On this note, ExceptionUtils#getCause(Throwable)/(Throwable, String[])
> is a candidate for this, although these methods are deprecated. The
> only problem is that an empty String array is currently treated
> differently than a null String[]
On Mon, Apr 11, 2011 at 1:31 PM, Gary Gregory wrote:
> Hi All:
>
> I am now realize that what we are stumbling along with Pair has already been
> done in org.apache.commons.collections.keyvalue, generics and all. Different
> class names but the same ideas.
>
> So... it sure would be nice to avoid
Drop keyvalue in favour of Pair? :)
More seriously; keep Pair (or keyvalue if that's a better name) in
Lang, and make Collections depend on Lang for the core pair concept.
Hen
On Mon, Apr 11, 2011 at 11:31 AM, Gary Gregory wrote:
> Hi All:
>
> I am now realize that what we are stumbling along w
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=7184&projectId=97
Build statistics:
State: Failed
Previous State: Ok
Started at: Mon 11 Apr 2011 18:32:53 +
Finished at: Mon 11 Apr 2011 18:34:46 +
Total time: 1m 53s
Build Trigger: Schedule
Build
Hi All:
I am now realize that what we are stumbling along with Pair has already been
done in org.apache.commons.collections.keyvalue, generics and all. Different
class names but the same ideas.
So... it sure would be nice to avoid creating the same thing in [lang] but
with different class names.
On Mon, Apr 11, 2011 at 2:14 PM, Gary Gregory wrote:
> On Mon, Apr 11, 2011 at 1:52 PM, Stephen Colebourne
> wrote:
>
>> I fixed the Map.Entry equals/hashCode compliance.
>>
>> I shortened the toString form to omit the class name, as it is
>> superfluous -> (A,B)
>>
>> Out library uses square bra
On Mon, Apr 11, 2011 at 1:52 PM, Stephen Colebourne wrote:
> I fixed the Map.Entry equals/hashCode compliance.
>
> I shortened the toString form to omit the class name, as it is
> superfluous -> (A,B)
>
> Out library uses square brackets, but I can live with round.
>
> I don't believe that requiri
On Mon, Apr 11, 2011 at 1:52 PM, Stephen Colebourne wrote:
> I fixed the Map.Entry equals/hashCode compliance.
>
> I shortened the toString form to omit the class name, as it is
> superfluous -> (A,B)
>
> Out library uses square brackets, but I can live with round.
>
> I don't believe that requiri
I fixed the Map.Entry equals/hashCode compliance.
I shortened the toString form to omit the class name, as it is
superfluous -> (A,B)
Out library uses square brackets, but I can live with round.
I don't believe that requiring every pair to carry around a format
string is viable. These must be sm
-1
The Pair class hashCode method is incompatible with Map.Entry.
(I haven't checked other parts of the release yet)
Stephen
On 9 April 2011 06:06, Henri Yandell wrote:
> Lang is ready to consider 3.0 release again.
>
> RC2 is available here:
>
> http://people.apache.org/~bayard/commons-lan
There is no aversion to customizing toString(). You said your choices
were subclassing, delegating, or convince the Commons community to
change the Pair class. If the Pair class isn't changed, then you're left
with the first two options. Personally, I prefer using the "has a"
pattern over the "
On Mon, Apr 11, 2011 at 5:24 PM, Phil Steitz wrote:
> On 4/11/11 8:40 AM, Stephen Colebourne wrote:
>> On 11 April 2011 16:14, Phil Steitz wrote:
>>> The point of keeping a working Ant build is for users who want to
>>> build from source and are not Maven users (many, many users in the
>>> real w
On 11 April 2011 17:24, Phil Steitz wrote:
> We can argue about this and speculate, but I have done the work to
> restore the Ant build for the 3.0 release and I would really like to
> give those users who want to be able to build a [lang] jar from
> source without downloading boatloads of irrelev
On Mon, Apr 11, 2011 at 12:19 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
> Delegating is trivial in Eclipse - it will write the code for you. As for
> delegating versus "rolling your own" - delegating leverages the code
> maturity and unit tests of the delegate.
>
Roger that. Sp
On 4/11/11 8:40 AM, Stephen Colebourne wrote:
> On 11 April 2011 16:14, Phil Steitz wrote:
>> The point of keeping a working Ant build is for users who want to
>> build from source and are not Maven users (many, many users in the
>> real world).
> I don't believe there are many of those users. Mos
Delegating is trivial in Eclipse - it will write the code for you. As
for delegating versus "rolling your own" - delegating leverages the code
maturity and unit tests of the delegate.
-Adrian
On 4/11/2011 9:16 AM, Gary Gregory wrote:
On Mon, Apr 11, 2011 at 10:12 AM, Matt Benson wrote:
On
On Mon, Apr 11, 2011 at 11:40 AM, Stephen Colebourne
wrote:
> On 11 April 2011 16:14, Phil Steitz wrote:
> > The point of keeping a working Ant build is for users who want to
> > build from source and are not Maven users (many, many users in the
> > real world).
>
> I don't believe there are many
On Mon, Apr 11, 2011 at 10:12 AM, Matt Benson wrote:
> On Mon, Apr 11, 2011 at 9:00 AM, Gary Gregory
> wrote:
> > Hi All:
> >
> > I added a test to verify the default Pair toString behavior.
> >
> > For me to replace our custom Pair class at work, I need to customize the
> to
> > String behavior
On 11 April 2011 16:14, Phil Steitz wrote:
> The point of keeping a working Ant build is for users who want to
> build from source and are not Maven users (many, many users in the
> real world).
I don't believe there are many of those users. Most just pickup the jar.
I oppose duplicate build sys
Why not make your custom Pair class a delegator?
-Adrian
On 4/11/2011 7:00 AM, Gary Gregory wrote:
Hi All:
I added a test to verify the default Pair toString behavior.
For me to replace our custom Pair class at work, I need to customize the to
String behavior.
Subclassing ImmutablePair and M
On 4/10/11 11:44 PM, Jörg Schaible wrote:
> Hi Hen,
>
> Henri Yandell wrote:
>
>> On Sun, Apr 10, 2011 at 1:43 PM, Phil Steitz
> [snip]
>
>>> * One last nit - why did we decide to dump the Ant build. Version
>>> 2.6 seems to have a working Ant build. Why wouldn't the same build
>>> work for 3.0. I
On Mon, Apr 11, 2011 at 10:03 AM, Matt Benson wrote:
> On Mon, Apr 11, 2011 at 9:23 AM, Matt Benson wrote:
>> On Sun, Apr 10, 2011 at 10:51 PM, Matt Benson wrote:
>>> On Sun, Apr 10, 2011 at 7:17 PM, Henri Yandell wrote:
On Sun, Apr 10, 2011 at 1:43 PM, Phil Steitz wrote:
> -0
>
>
This is all true, but I would suspect that while components in "proper" are
likely to follow this pattern, those in "dormant" have a high probability of
staying that way, although there are some good ideas there.
Ralph
On Apr 11, 2011, at 7:58 AM, Phil Steitz wrote:
> On 4/11/11 5:46 AM, Steph
On Mon, Apr 11, 2011 at 10:58 AM, Phil Steitz wrote:
> On 4/11/11 5:46 AM, Stephen Colebourne wrote:
> > My preference would be a standard labelling across commons (and later
> > perhaps other projects).
> >
> > This is a lot easier to do than moving projects about in a VCS,
> > changing JIRA, ma
On Mon, Apr 11, 2011 at 9:23 AM, Matt Benson wrote:
> On Sun, Apr 10, 2011 at 10:51 PM, Matt Benson wrote:
>> On Sun, Apr 10, 2011 at 7:17 PM, Henri Yandell wrote:
>>> On Sun, Apr 10, 2011 at 1:43 PM, Phil Steitz wrote:
-0
Would like to see findbugs warnings sorted. I have not r
On 4/11/11 5:46 AM, Stephen Colebourne wrote:
> My preference would be a standard labelling across commons (and later
> perhaps other projects).
>
> This is a lot easier to do than moving projects about in a VCS,
> changing JIRA, mailing lists etc. Plus it doesn't break any URLs.
>
> Simply have a
On Sun, Apr 10, 2011 at 10:51 PM, Matt Benson wrote:
> On Sun, Apr 10, 2011 at 7:17 PM, Henri Yandell wrote:
>> On Sun, Apr 10, 2011 at 1:43 PM, Phil Steitz wrote:
>>> -0
>>>
>>> Would like to see findbugs warnings sorted. I have not retested
>>> after Luc's fixes, but I in addition to the ones
On Mon, Apr 11, 2011 at 10:14 AM, Matt Benson wrote:
> On Mon, Apr 11, 2011 at 9:06 AM, Gary Gregory
> wrote:
> > Also:
> >
> > Why go through this complicated code path:
> >
> > StringBuilder builder = new
> StringBuilder(ClassUtils.getShortClassName(this,
> > null));
> >
> > instead of the sim
Hi All:
Should we deprecate ClassUtils getShortClassName in favor of Class
getSimpleName?
The behavior of getShortClassName is undocumented for arrays in the Javadoc
and is different from getSimpleName.
When I replace the guts of getShortClassName to call getSimpleName, one test
fails:
junit.fr
On Mon, Apr 11, 2011 at 9:06 AM, Gary Gregory wrote:
> Also:
>
> Why go through this complicated code path:
>
> StringBuilder builder = new StringBuilder(ClassUtils.getShortClassName(this,
> null));
>
> instead of the simpler:
>
> StringBuilder builder = new StringBuilder(this.getClass().getSimple
On Mon, Apr 11, 2011 at 9:00 AM, Gary Gregory wrote:
> Hi All:
>
> I added a test to verify the default Pair toString behavior.
>
> For me to replace our custom Pair class at work, I need to customize the to
> String behavior.
>
> Subclassing ImmutablePair and MutablePair to override toString smel
Also:
Why go through this complicated code path:
StringBuilder builder = new StringBuilder(ClassUtils.getShortClassName(this,
null));
instead of the simpler:
StringBuilder builder = new StringBuilder(this.getClass().getSimpleName());
?
Thank you,
Gary
On Mon, Apr 11, 2011 at 10:00 AM, Gary G
Hi All:
I added a test to verify the default Pair toString behavior.
For me to replace our custom Pair class at work, I need to customize the to
String behavior.
Subclassing ImmutablePair and MutablePair to override toString smells nasty.
What about adding a formatString ivar which will be used
My preference would be a standard labelling across commons (and later
perhaps other projects).
This is a lot easier to do than moving projects about in a VCS,
changing JIRA, mailing lists etc. Plus it doesn't break any URLs.
Simply have a label (ie. an icon like the CC icons) that summarises
the
On 11 April 2011 06:21, Phil Steitz wrote:
> On 3/30/11 1:48 PM, sebb wrote:
>> On 30 March 2011 21:37, Phil Steitz wrote:
>>> On 3/30/11 1:21 PM, Mark Thomas wrote:
On 30/03/2011 07:17, Phil Steitz wrote:
> The tag is here:
> http://svn.apache.org/repos/asf/commons/proper/pool/tags/
Hi.
On Mon, Apr 11, 2011 at 01:39:51AM -0700, Henri Yandell wrote:
> Noting that this didn't get a reply.
I had not seen it pass. [Mails from "commons" are sometimes rejected by my
provider under the (false) assumption that they are spam...]
> -- Forwarded message --
> From: Oli
Noting that this didn't get a reply.
-- Forwarded message --
From: Olivier Lefevre
Date: Thu, Mar 31, 2011 at 12:15 AM
Subject: Solver deprecations in common maths 2.2
To: u...@commons.apache.org
All solve methods of UnivariateRealSolver are now deprecated: two
were deprecated i
> I'm having a problem distinguishing "dormant" from "attic". Just because one
> had releases and the other didn't they should go to different places for
> their final resting place?
I also fear this leads to more confusion than it helps.
> I'm not clear why commons should have an attic (or do
53 matches
Mail list logo
