--- robert burrell donkin <[EMAIL PROTECTED]> wrote: > On Thursday, December 5, 2002, at 07:20 PM, Morgan > Delagrange wrote: > > > So it seems like the point is not > "ConstructorUtils in > > beanutils: a bad idea", but rather "Reflection > classes > > in beanutils: a bad idea". It's inappropriate to > -1 > > adding ConstructorUtils to beanutils on the basis > of > > scope, since that is where such classes currently > > belong. > > i only threatened to -1 after trying quite a few > times to get rodney to > discuss his commit.
The only email I saw, Rodney responded to in a timely fashion. > 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. 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. Precedent supports Rodney, so the onus is largely on you. You're recommending deprecation of a released, public-facing API; Rodney is not. > or to reply to > questions afterwards, > then it would have been very reasonable to veto his > contribution since he > was asking other committers to support code they > were unhappy with. > luckily, this has turned out not to be the case. > > > If you want to move reflection code out of > > beanutils, let's do it all at once with a proper > > discussion and vote, not piecemeal via guerilla > > vetoes. > > FWIW we've had lots and lots and lots of discussions > on this issue. I know, I've followed some of the discussion. > 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. > 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. > 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? > - robert > > > - Morgan > > > > --- robert burrell donkin > > <[EMAIL PROTECTED]> wrote: > >> On Thursday, December 5, 2002, at 03:25 PM, > Rodney > >> Waldhoff wrote: > >> > >> <snip> > >> > >>> Looking through the archives, I now see the > thread > >> named > >>> "[beanutils][lang][PROPOSAL] deprecated > beanutils > >> version of MethodUtils" > >>> [1] which apparently should have been flagged > >> "[VOTE]", if that was > >>> intended to be a binding vote. > >> > >> no, that thread wasn't binding. that's one reason > >> why i wanted to try to > >> engage you in debate rather than just -1'ing the > >> commit straight away :) > >> > >>> I'd be OK with leaving beanutils as the > repository > >> for reflection oriented > >>> stuff. In light of this thread, I think I'd > >> prefer to create true > >>> reflection oriented commons component. I'm > >> strongly opposed to moving a > >>> bunch of stuff into lang because it seems > somehow > >> central or widely > >>> applicable. I'd rather see a bunch of focused > >> modules with well defined > >>> scope (however tiny) than a grand utilties > >> framework, and my reading of > >>> the commons charter says it agrees with me. > >> > >> though i agree about your point in general, the > >> reflection code fits > >> perfectly into lang's spec. they are utility > classes > >> for package java.lang. > >> reflect. > >> > >> AFAIK class and reflect(ion?) were intended to be > >> introspection-alternatives. they need to rely on > >> solid, low level > >> reflection utilities. > >> > >> - robert > >> > >> > >> -- > >> To unsubscribe, e-mail: > >> > <mailto:[EMAIL PROTECTED]> > >> For additional commands, e-mail: > >> <mailto:[EMAIL PROTECTED]> > >> > > > > > > ===== > > Morgan Delagrange > > http://jakarta.apache.org/taglibs > > http://jakarta.apache.org/commons > > http://axion.tigris.org > > http://jakarta.apache.org/watchdog > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Mail Plus - Powerful. Affordable. Sign up > now. > > http://mailplus.yahoo.com > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]. > > org> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]. > > org> > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > ===== Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
