On Fri, 6 Dec 2002, Costin Manolache wrote:
> Date: Fri, 06 Dec 2002 07:41:08 -0800 > From: Costin Manolache <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
