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 Wed, 28 Jul 2004 19:24:30 GMT
On 26 Jul 2004, at 17:59, Craig McClanahan wrote:
> On Mon, 26 Jul 2004 20:07:59 +1200, Simon Kitching
> <> wrote:
>> On Mon, 2004-07-26 at 19:13, robert burrell donkin wrote:


>> And will the Digester 1.x series be committed to depending on
>> collections, with the happy coincidence that the BeanUtils "extended"
>> jar also happens to satisfy Digester's need for commons-collections?
> The whole goal of this exercise has been to decouple both Digester and
> BeanUtils from the Commons Collections dependency.  It's a relatively
> large JAR file to require solely for two or three classes.
> Before these changes, Digester depended on Collections both directly
> and indirectly.  The checkin of o.a.c.d.ArrayStack fixed the direct
> dependence, but broke backwards compatibility and needs to be undone.
> But, from a Digester viewpoint, we're going to depend on BeanUtils no
> matter what, and will be able to leverage what BeanUtils does to solve
> the problem.  The ideal end game, then, is that Digester 1.6 will work
> with either
> * BeanUtils >= 1.7 (including o.a.c.c.ArrayStack)
> * BeanUtils < 1.7 plus Collections x.y
> The former will be (at a minimum) recommended in order to pick up
> BeanUtils bugfixes, but the latter should make life easier for
> migrations and containers.


i think that this is the right solution. we'll ship digester without 
the extra collection classes.

i plan to cut a beanutils 1.7.1 bug fix release sometime soon. we can 
probably go one better than the above (for downstream container folks). 
for the modular jar set, we can split out the collections classes from 
the beanutils-core into a separate modular jar. this should allow 
containers to depend on beanutils-core.jar plus 2.x or 3.x collections 
or the modular beanutils-collection-utils.jar (except with a better 

now this is sorted and the other releases i've been cutting are out of 
the way, i'm going to start working through the release plan 

the major item on the agenda is to review the maturity of the newer 
code. simon's worked very hard on the plug-in stuff and that's probably 
where we need to review to ensure that all the APIs are right before 
they are fixed by this release. simon - are they any areas in the API 
that you have any concerns about?

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message