Re: [beanutils] moving reflection classes out of beanutils

[robert burrell donkin]

On Thursday, December 5, 2002, at 08:39 PM, Morgan Delagrange wrote:

--- robert burrell donkin
<[EMAIL PROTECTED]> wrote:

<snip>

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 maintenance.

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.

<snip>

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 versions.

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 rodney?

- robert


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>