commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [digester] dependencies for 1.6 release
Date Thu, 22 Jul 2004 22:23:53 GMT
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 

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.


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:
For additional commands, e-mail:

View raw message