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: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
|