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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
