On Mon, 2004-07-26 at 19:13, robert burrell donkin wrote: > hi simon > > we all agree that the long term solution is to use an ArrayStack > packaged as part of digester. in fact, if we new then what we know now > about developing libraries, we have done this from the start. > > i also agree that it's a trick and a hack but in my mind, it's the > least worst solution. > > ArrayStack is stable and mature. there have been no code changes (that > i can see) in the last 18 months > (http://cvs.apache.org/viewcvs.cgi/jakarta-commons/collections/src/ > java/org/apache/commons/collections/ArrayStack.java) and there seem to > be no substantial ones since the code was donated from Digester. this > means that it's very, very unlikely that version problems will occur. > > even setting aside the issue of containers (and the risks of insoluble > binary compatibility issues), shipping a binary incompatible version of > digester would cause compatibility problems for struts users (and > anyone else using a framework dependent on digester). they would not be > able to drop the new digester jar in as a replacement for the struts > digester dependency. yes, they could recompile the struts release from > source but i'm keen to see the new enhancements used as widely as > possible. this means binary compatibility. >
Ok, so the problem is that lib A (eg struts) depends on Digester 1.5. And lib B depends on Digester 1.6. And a user app then depends on lib A and lib B. We don't want them to have to find versions of A and B which have been compiled against the same Digester release. Instead we want to provide a version of Digester that is compatible with both A and B. I guess the ugliness is only within BeanUtils, not Digester, in that BeanUtils is bundling the "alien" class, and Digester just wants the o.a.c.c.ArrayStack class to be *somewhere* in the classpath. Are you intending to have two BeanUtils jars, the "standard" one and an "extended" convenience jar that tosses in some external classes? With this, I feel a bit more comfortable about this. After all, users can still use the latest Digester + the latest BeanUtils "standard" release + a normal collections jar, and get exactly the same result as using the BeanUtils "extended" release + no collections lib. [sorry I haven't been following the BeanUtils emails more closely]. What is the plan for untangling this later? Will BeanUtils 1.x always depend on collections, with this "extended" jar option available that includes the necessary dependencies? 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? Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
