On 22 Jul 2004, at 13:51, Shapira, Yoav wrote:
Hi,
hi Yoav
My take on this is probably overly simplistic, but I'll state it anyways:
- It Digester depends on BeanUtils at all, it should depend on the latest version.
digester needs to depend on beanutils but we've tried to give the user as large a choice of releases as possible. the latest beanutils would therefore be recommended but not demanded.
- If Digester needs only a tiny subset of BeanUtils or Collections functionality, then copying those classes is acceptable, but if it's a bigger set we should just keep the dependency.
digester needs only a very small subset of collections. by including more, we would have to choose to support either the 2.x series or the 3.x series of releases since these are incompatible. unless we address it (as we are trying to now) this incompatibility issue will likely cause many users a lot of pain. think (for example) if tomcat and struts indirectly depended on incompatible versions of the collections library.
this subset is pretty much covered by the extra collection packaged classes added to beanutils. so, we could just demand that people upgrade the beanutils version. on the other hand, the number of classes is small so we could just add the classes to digester and then keep the current dependency.
Now I'll go on a little side track, but it's relevant to this discussion: - Partially because of these complex dependency issues, Tomcat 5.1 (in progress, not yet released), is largely copying the subset of Digester that it needs into local (org.apache.catalina/org.apache.tomcat) classes.
i've heard a rumour that weblogic does something similar.
This is sub-optimal to everyone I think.
yep.
we are trying to address the issue of dependencies but it's quite a long process.
- So I'd like to step back and ask which ones of these dependencies are really necessary. I see commons-collections as an add-on to the JDK collections aimed at performance, decorations, and special cases. I don't buy that the performance gains of FastHashMap, for example, are important enough to justify the commons-collections dependency, especially for a larger project like Tomcat where this performance gain is dwarfed by losses elsewhere (not related to commons-collections).
that's pretty much the opinion of everyone here. deciding to depend on the collection packaged version of FastHashMap was a mistake. we are trying to address this one. the next beanutils and digester releases will not depend on commons collections.
it would be very difficult to factor out the beanutils dependency (without breaking backwards compatibility) and i'm not sure how much benefit this change would be for downstream users (but i'd be interested to find out).
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
