Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 47900 invoked from network); 5 Dec 2002 22:59:21 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 5 Dec 2002 22:59:21 -0000 Received: (qmail 2751 invoked by uid 97); 5 Dec 2002 23:00:30 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 2731 invoked by uid 97); 5 Dec 2002 23:00:29 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 2715 invoked by uid 98); 5 Dec 2002 23:00:29 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Thu, 5 Dec 2002 22:59:39 +0000 Subject: Re: [beanutils] moving reflection classes out of beanutils Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: robert burrell donkin To: "Jakarta Commons Developers List" Content-Transfer-Encoding: 7bit In-Reply-To: <20021205203928.95974.qmail@web12407.mail.yahoo.com> Message-Id: <3B7B3170-08A5-11D7-AC90-003065DC754C@blueyonder.co.uk> X-Mailer: Apple Mail (2.482) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 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. >> 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: For additional commands, e-mail: