You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Morgan Delagrange <md...@yahoo.com> on 2002/12/05 21:39:28 UTC
Re: [beanutils] moving reflection classes out of beanutils (was: Re: [beanutils] ConstructorUtils in beanutils: a bad idea)
--- robert burrell donkin
<ro...@blueyonder.co.uk> 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
> > <ro...@blueyonder.co.uk> 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:
> >>
> <ma...@jakarta.apache.org>
> >> For additional commands, e-mail:
> >> <ma...@jakarta.apache.org>
> >>
> >
> >
> > =====
> > 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:commons-dev-unsubscribe@jakarta.apache.
> > org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.
> > org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
=====
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Saturday, December 7, 2002, at 06:59 AM, Costin Manolache wrote:
> Craig R. McClanahan wrote:
>
>>> It doesn't quite matter. There are people using it ( digester, other
>>> projects), it was released - we have to live with it. We may learn a
>>> lesson about APIs and use it next time, but as long as it does what it
>>> is
>>> supposed to do and works - you can't remove it.
>
>> I believe that adding a dependency on [lang] or [reflect] would itself be
>> grounds for a 2.x version number for [beanutils], even with no other
>> changes (although there would undoubtedly be some).
>
> I don't know.
>
> this kind of stuff.
>
> If the [reflect] package will have the same features and better API -
> then it may be better to mark beanutils as "stable"/"closed" and
> migrate modeler, digester, etc directly to [reflect]. I don't see why
> would we need a 2.x version.
the plan was to separate out just the reflection utilities leaving
beanutils focused exclusively on introspection. digester (for example)
would still need to use beanutils for introspection but may want to
migrate to the improved reflection utilities.
the critical flaw with the old MethodUtils API is that the method
contracts are not written in a way that makes it clear what are bugs and
what aren't. fixing this will mean changing the method symantics. the
reflection methods will work better but differently. i'd say that's a good
reason for making it version 2.0.
components using beanutils expect that MethodUtils should work to the java
language specification. users who use MethodUtils directly rely on the
method descriptions. they can quite reasonable rely on a feature of the
current code which deviates from the correct behaviour (as far as the
other components are concerned).
the flaw also makes it impossible to create comprehensive test cases.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Saturday, December 7, 2002, at 09:32 PM, Henri Yandell wrote:
<snip>
> So... we let Robert/Stephen/others finish up with reflect in lang while
> copying across modifications that occur to those areas in beanutils...
unfortunately, the modifications and fixes can't be copied across.
the public API of the MethodUtils in beanutils is not precisely defined
enough to allow this. we need a new API which has precise, testable method
definitions so that it's clear what a bug is.
> then we have big argument then? :)
true
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 6 Dec 2002, Costin Manolache wrote:
> Craig R. McClanahan wrote:
>
> I don't know.
>
> this kind of stuff.
>
> If the [reflect] package will have the same features and better API -
> then it may be better to mark beanutils as "stable"/"closed" and
> migrate modeler, digester, etc directly to [reflect]. I don't see why
> would we need a 2.x version.
>
> I don't think we need more than a component for this kind of stuff -
> or at least I would use a single component ( even beanutils ) over
> some reflection that is split in more components. Matter of taste,
> of course - but also complexity, dependencies, spaghetti.
>
Because reflection and beans are different things. Many things will want
to do reflection, but won't have any interest in some form of bean API.
The same holds for BeanUtils' Convertor system. Many things will want to
use this, but have no interest in Beans.
Having to deal with a library which is created with a context of JavaBeans
means that the Convertor and Reflection APIs will be tainted by this
context.
> > It's clear that ConstructorUtils and MethodUtils belong together,
> > wherever they end up. But it seems less clear that a move would mean
> > *deleting* MethodUtils from [beanutils]. It's straightforward to leave
> > the existing APIs available (for backwards compatibility), but as wrappers
> > around calls to the new functionality, probably deprecated but at least
> > kept through a 2.x version lifecycle. That way, the actual functionality
> > is still in one place for easy maintenance/enhancement, we can fix the
> > method names in the new versions, and users of MethodUtils can migrate in
> > a controlled manner, at their own leisure.
>
> My point is that it would be better if the new package would focus
> on doing what it has to do - API, implementation, features.
Yep. And ConstructorUtils/MethodUtils are outside the scope of BeanUtils
in my view, even if the PROPOSAL does provide some mention of
reflection/introspection utilities.
> When it's ready - we can decide if it makes sense to deprecate ( freeze )
> beanutils entirely, implement it as a wrapper for backward compat -
> or keep it if it fits a different niche.
Agreed. It's always better to debate a piece of code when it's sitting and
ready for inclusion in a particular library somewhere, especially with
something like reflection where it's pretty independent of the surrounding
library.
So... we let Robert/Stephen/others finish up with reflect in lang while
copying across modifications that occur to those areas in beanutils...
then we have big argument then? :)
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Costin Manolache <cm...@yahoo.com>.
Craig R. McClanahan wrote:
>> It doesn't quite matter. There are people using it ( digester, other
>> projects), it was released - we have to live with it. We may learn a
>> lesson about APIs and use it next time, but as long as it does what it is
>> supposed to do and works - you can't remove it.
> I believe that adding a dependency on [lang] or [reflect] would itself be
> grounds for a 2.x version number for [beanutils], even with no other
> changes (although there would undoubtedly be some).
I don't know.
this kind of stuff.
If the [reflect] package will have the same features and better API -
then it may be better to mark beanutils as "stable"/"closed" and
migrate modeler, digester, etc directly to [reflect]. I don't see why
would we need a 2.x version.
I don't think we need more than a component for this kind of stuff -
or at least I would use a single component ( even beanutils ) over
some reflection that is split in more components. Matter of taste,
of course - but also complexity, dependencies, spaghetti.
( well, you can do all the introspection witha single class - both ant and
tomcat3 are basically doing that ).
> It's clear that ConstructorUtils and MethodUtils belong together,
> wherever they end up. But it seems less clear that a move would mean
> *deleting* MethodUtils from [beanutils]. It's straightforward to leave
> the existing APIs available (for backwards compatibility), but as wrappers
> around calls to the new functionality, probably deprecated but at least
> kept through a 2.x version lifecycle. That way, the actual functionality
> is still in one place for easy maintenance/enhancement, we can fix the
> method names in the new versions, and users of MethodUtils can migrate in
> a controlled manner, at their own leisure.
My point is that it would be better if the new package would focus
on doing what it has to do - API, implementation, features.
When it's ready - we can decide if it makes sense to deprecate ( freeze )
beanutils entirely, implement it as a wrapper for backward compat -
or keep it if it fits a different niche.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 6 Dec 2002, Costin Manolache wrote:
> robert burrell donkin wrote:
>
> > what we have is clear duplication. twice the support and twice the
> > maintenance.
>
> Nobody asks you to support 2 versions. There is nothing wrong with
> duplication ( at least in commons ). You can just maintain and support the
> version you like.
Nothing illegal with 2 versions anyway. If there are duplicate versions,
with no difference in religion between those versions, I would question
the rightness. Especially if it came from the same 'group' of developers.
[Not that I'm stating that Commons is a group of developers in any way]
> >> 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.
>
> It doesn't quite matter. There are people using it ( digester, other
> projects), it was released - we have to live with it. We may learn a lesson
> about APIs and use it next time, but as long as it does what it is supposed
> to do and works - you can't remove it.
So work stops on beanutils and BeanUtilsTNG is created? Why can't it be
removed? I agree that such a removal should imply a large version number
change, ie) BeanUtils 2.0, but what states that Commons libraries have to
follow slow-release deprecation methods?
> This start to look like dependency spaghetti to me, and it does create
> problems.
Yep. Reality is we are going to have N libraries with M dependencies,
where N and M will only get bigger at a rate slightly faster than we can
manage it.
Do we need to have a common plan in Commons? Or do we do our best to
ensure there are no dependencies between projects, ie) each one is
stand-alone and has some kind of copying system for internal function
calls [ie) we copy the jar, change the bytecode to a different package
name, an obfuscated one].
> > 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.
>
> Good. Then maintain and support the other version.
While this kind of view is an important one to have in the community [as
detailed in a long thread on jakarta-general or apache-community] in that
it helps to deal with potential forking and potential project-death, it
does seem that the philosophy should be to work together until such a
point as working together is not possible, and then to allow the
community-healing mores to come into play.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 6 Dec 2002, Costin Manolache wrote:
> Date: Fri, 06 Dec 2002 07:41:08 -0800
> From: Costin Manolache <cm...@yahoo.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: commons-dev@jakarta.apache.org
> Subject: Re: [beanutils] moving reflection classes out of beanutils
>
> robert burrell donkin wrote:
>
> > what we have is clear duplication. twice the support and twice the
> > maintenance.
>
> Nobody asks you to support 2 versions. There is nothing wrong with
> duplication ( at least in commons ). You can just maintain and support the
> version you like.
>
> >> 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.
>
> It doesn't quite matter. There are people using it ( digester, other
> projects), it was released - we have to live with it. We may learn a lesson
> about APIs and use it next time, but as long as it does what it is supposed
> to do and works - you can't remove it.
>
> This start to look like dependency spaghetti to me, and it does create
> problems.
>
I believe that adding a dependency on [lang] or [reflect] would itself be
grounds for a 2.x version number for [beanutils], even with no other
changes (although there would undoubtedly be some).
>
> > 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.
>
> Good. Then maintain and support the other version.
>
>
> > 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?
>
> ), it's reasonably clean. If Rodney doesn't want to support it - I can and
> I suppose other people will.
> Beanutils is used in tomcat, and if a bug happens we'll have to fix it
> anyway, and I think we can handle that.
>
It's clear that ConstructorUtils and MethodUtils belong together,
wherever they end up. But it seems less clear that a move would mean
*deleting* MethodUtils from [beanutils]. It's straightforward to leave
the existing APIs available (for backwards compatibility), but as wrappers
around calls to the new functionality, probably deprecated but at least
kept through a 2.x version lifecycle. That way, the actual functionality
is still in one place for easy maintenance/enhancement, we can fix the
method names in the new versions, and users of MethodUtils can migrate in
a controlled manner, at their own leisure.
> Costin
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Costin Manolache <cm...@yahoo.com>.
robert burrell donkin wrote:
> what we have is clear duplication. twice the support and twice the
> maintenance.
Nobody asks you to support 2 versions. There is nothing wrong with
duplication ( at least in commons ). You can just maintain and support the
version you like.
>> 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.
It doesn't quite matter. There are people using it ( digester, other
projects), it was released - we have to live with it. We may learn a lesson
about APIs and use it next time, but as long as it does what it is supposed
to do and works - you can't remove it.
This start to look like dependency spaghetti to me, and it does create
problems.
> 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.
Good. Then maintain and support the other version.
> 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?
), it's reasonably clean. If Rodney doesn't want to support it - I can and
I suppose other people will.
Beanutils is used in tomcat, and if a bug happens we'll have to fix it
anyway, and I think we can handle that.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Friday, December 6, 2002, at 06:53 PM, Costin Manolache wrote:
> robert burrell donkin wrote:
>
>> the guidelines have an inbuilt mechanism whereby components may - if they
>> wish - prevent a new existing commons committer joining. that is, they
>> can
>> veto the addition of the committers name to the list of developers for
>> the
>> component.
>
> With a valid technical reason.
>
> Probably it can be done in a majority vote - but I certainly hope we'll
> not reach that point.
+1
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Costin Manolache <cm...@yahoo.com>.
robert burrell donkin wrote:
>
> the guidelines have an inbuilt mechanism whereby components may - if they
> wish - prevent a new existing commons committer joining. that is, they can
> veto the addition of the committers name to the list of developers for the
> component.
With a valid technical reason.
Probably it can be done in a majority vote - but I certainly hope we'll
not reach that point.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Friday, December 6, 2002, at 04:27 PM, Rodney Waldhoff wrote:
<snip>
> And I'm convinced that lang isn't the right place either. Let's split the
> difference and propose commons-reflect or commons-reflection or whatever,
> and end this thread.
+1 but i don't have the energy to force this through.
it's very frustrating for me.
i've been working for some time on creating a solid MethodUtils with a
good API and a comprehensive set of unit tests. this version is taking
shape in lang.
i'd also like to see a new bug fix beanutils release very soon which is
why i switched to fixing beanutils bugs.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Morgan Delagrange <md...@yahoo.com>.
--- robert burrell donkin
<ro...@blueyonder.co.uk> wrote:
<snip/>
>
> the guidelines have an inbuilt mechanism whereby
> components may - if they
> wish - prevent a new existing commons committer
> joining. that is, they can
> veto the addition of the committers name to the list
> of developers for the
> component.
>
> - robert
>
Are you sure about that? I don't see that anywhere:
http://jakarta.apache.org/commons/charter.html
AFAIK there are no restrictions on existing committers
working on other existing components. If you're
implying that committers can exercise their veto on
the actual commit of a new developer's name to the
STATUS file, that's not so. Commits can only be
vetoed for valid technical reasons. I can't imagine
the technical justification for "you can't work on my
component".
Adding your name to the STATUS file is a courtesy.
Nobody should be ostracized for not doing it:
Version 1.8:
http://cvs.apache.org/viewcvs/jakarta-commons/beanutils/STATUS.html#rev1.8
Version 1.6:
http://cvs.apache.org/viewcvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/MethodUtils.java#rev1.6
- Morgan
=====
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Friday, December 6, 2002, at 04:27 PM, Rodney Waldhoff wrote:
> On Thu, 5 Dec 2002, robert burrell donkin wrote:
>
>> On Thursday, December 5, 2002, at 08:39 PM, Morgan Delagrange wrote:
>>> --- robert burrell donkin
>>> <ro...@blueyonder.co.uk> 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.
>>
>
> I really offended by this comment, Robert. The commit you refer to was
> not only well within my rights *and* responsibilities, clearly following
> both the spirit and letter of the asf, jakarta, and jakarta-commons
> guidelines, but also well within the bounds of politeness and courtesy.
> This commit was small (one class, about ~300 lines counting comments and
> blanks), unobtrusive (no new dependencies, configuration, extra processing
> or memory use was introduced), fully backwards compatible, and well within
> the scope of the project. The "commit then review" protocol is clearly
> appropriate (and polite) in this circumstance. If I need your explicit
> approval before making a small, unobtrusive, fully backwards compatible
> and in scope commit, then Guideline #15 (Each committer has karma to all
> the packages) is meaningless.
i'm sorry you feel this way rodney. i'd thought i'd made it clear that
these criticisms don't apply to you.
i was trying (and failing) to speak in general terms.
the guidelines have an inbuilt mechanism whereby components may - if they
wish - prevent a new existing commons committer joining. that is, they can
veto the addition of the committers name to the list of developers for the
component.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by Rodney Waldhoff <rw...@apache.org>.
On Thu, 5 Dec 2002, robert burrell donkin wrote:
> On Thursday, December 5, 2002, at 08:39 PM, Morgan Delagrange wrote:
> > --- robert burrell donkin
> > <ro...@blueyonder.co.uk> 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.
>
I really offended by this comment, Robert. The commit you refer to was
not only well within my rights *and* responsibilities, clearly following
both the spirit and letter of the asf, jakarta, and jakarta-commons
guidelines, but also well within the bounds of politeness and courtesy.
This commit was small (one class, about ~300 lines counting comments and
blanks), unobtrusive (no new dependencies, configuration, extra processing
or memory use was introduced), fully backwards compatible, and well within
the scope of the project. The "commit then review" protocol is clearly
appropriate (and polite) in this circumstance. If I need your explicit
approval before making a small, unobtrusive, fully backwards compatible
and in scope commit, then Guideline #15 (Each committer has karma to all
the packages) is meaningless.
Moreover, when making a commit that fails to meet any one of these
criteria, I've very consistently brought this to the attention of the
development community, before, immediately after, or both before and after
making the commit, no matter how long I've been working on or with the
project, or for that matter whether or not I've been to primary developer
working on it, as you can see in [1] and [2] and [3] and [4] and [5] and
[6] and [7] and others.
I'm not disputing your right to question (i.e., review) this commit, but
don't suggest that it was inappropriate or impolite or somehow makes me a
bad citizen.
[1] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=76126>
[2] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=78100>
[3] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=344668>
[4] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=513101>
[5] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=525232>
[6] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=559250>
[7] <http://archives.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache.org&msgId=564947>
> the consensus which emerged from the lengthy discussions on this issue
> supports me, though.
That's not "consensus" in the standard meaning--there are those that
disagree with this approach. It's certainly not "consensus" in any formal
ASF sense, since there was no actual [VOTE] on the issue, so claiming it
as a matter of policy is questionable in my eyes.
> 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?
I'm trying real hard not to feel condescended to here Robert. I'm
willing to fulfill my responsiblities as an Apache committer and feel
I've got a pretty strong record of doing so.
(and from a different thread)
Costin> If duplication is a concern - then just use
Costin> beanutils ( however duplication is explicitely
Costin> allowed in commons AFAIK).
Robert> i've been convinced that beanutils is
Robert> not the right place for this code.
And I'm convinced that lang isn't the right place either. Let's split the
difference and propose commons-reflect or commons-reflection or whatever,
and end this thread.
- R.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [beanutils] moving reflection classes out of beanutils
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thursday, December 5, 2002, at 08:39 PM, Morgan Delagrange wrote:
> --- robert burrell donkin
> <ro...@blueyonder.co.uk> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>