On Mon, 26 Jul 2004 20:07:59 +1200, Simon Kitching <[EMAIL PROTECTED]> wrote:On Mon, 2004-07-26 at 19:13, robert burrell donkin wrote:
<snip>
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.
+1
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 name).
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 (http://wiki.apache.org/jakarta-commons/Digester/1_2e6_2e0ReleasePlan).
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
