commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [beanutils] moving reflection classes out of beanutils
Date Thu, 05 Dec 2002 22:59:39 GMT
On Thursday, December 5, 2002, at 08:39 PM, Morgan Delagrange wrote:
> --- robert burrell donkin
> <> wrote:


>> rodney hasn't been a regular contributor to
>> beanutils either in terms of
>> code or on the mailing lists. if he couldn't even be
>> bothered to ask
>> before making himself a committer
> He's not required to ask, only to indicate his
> participation.

asking is a matter of politeness and means that his participation is less 
likely to be vetoed.

a committer has responsibilities as well as rights. if i thought that a 
committer was just dumping code into a component and had no intention of 
maintaining that code, i wouldn't hesitate to veto.

rodney has convinced me that this isn't so in this case.

> Are his contributions less valid
> because they are recent?  You don't seem to be
> objecting to the quality of the code either, only to
> its location based on your opinion of what should or
> shouldn't be in beanutils.

what we have is clear duplication. twice the support and twice the 

if rodney couldn't supply a good reason why we should support and maintain 
two versions of the same code, then i wouldn't hesitate to veto the 
contribution on those grounds. but now he's offered one, we can (hopefully)
  make progress.

> Precedent supports Rodney, so the onus is largely on you.

the consensus which emerged from the lengthy discussions on this issue 
supports me, though.

> You're recommending deprecation of a released, public-facing API; Rodney
> is not.

the (beanutils) MethodUtils API sucks. it was written in haste and now in 
leisure, i regret that it was written in that way.


>> a veto is a way to force a discussion and vote on
>> whether ConstructorUtils
>> belongs in beanutils.
> A discussion, leading to a vote, on whether or not to
> support reflection in the beanutils package is also a
> way to force the issue.  But votes are more
> constructive than vetoes.

i haven't vetoed anything. i threatened to veto unless rodney offered up 
an explanation. it's not possible to have a discussion unless you have 
someone to discuss with.

>> we're already having a
>> discussion. maybe someone
>> will propose a vote later. so, it using the veto
>> shouldn't be necessary.
>>> Personally, beanutils seems like a logical home
>> for
>>> both of these classes, and I haven't seen the
>>> convincing argument for moving them.  So I'm -1 on
>>> moving them at this time.
>> moving MethodUtils to lang is a totally different
>> issue.
> I disagree, MethodUtils and ConstructorUtils are
> linked.  Shuffling them around independently is
> pointless.

versions of both classes already exist in lang.

adding ConstructorUtils to beanutils now means that both have to be 
deprecated or neither.

>> the previous discussions came to a consensus about
>> the right sequence for
>> events. right now, the reflect code in lang is still
>> young. the API's need
>> fixing and comprehensive test cases created for
>> them. only then will a
>> vote be called to deprecate MethodUtils and make
>> beanutils depend on lang.
> So until we actually decide to deprecate MethodUtils,
> Rodney's commit is valid, correct?

i haven't vetoed it, have i?

my position has always been that i'm not willing to maintain, support or 
develop two versions of the basic reflection classes. i've also been 
convinced that beanutils is not the right places for these canonical 

in terms of beanutils, i'm not willing to support a release with code in 
that no one is willing to support. therefore, i'd think about vetoing any 
contribution if i thought that no one was willing to offer support for 
that code and maintain it. but you're willing to do that for 
ConstructorUtils (and MethodUtils if it can't be deprecated), aren't you 

- robert

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message