commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: [digester] dependencies for 1.6 release
Date Mon, 26 Jul 2004 16:59:46 GMT
On Mon, 26 Jul 2004 20:07:59 +1200, Simon Kitching
<simon@ecnetwork.co.nz> wrote:
> 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.


It is actually worse than that ... if the application incudes a
subclass of org.apache.commons.digester.Digester, it will either work
or fail depending on which version of commons-digester.jar happens to
be found first in the class path.  That is why the commit I did
(creating o.a.c.d.ArrayStack) is broken.  That is *way* too fragile to
knowingly allow.

> 
> 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.
> 

Right.

> 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].
> 

I don't see a reason to make life harder on BeanUtils users by
splitting out this stuff.  I'd rather live with the temporary class
duplication (which the collections folks have indicated they are
unlikely to change), and resolve it later.

> 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?
> 

My view is that BeanUtils 1.x should package o.a.c.c.ArrayStack (and
the other collection classes that it did the same thing with),
"forever" through the 1.x lifetime.  The problem is that it's baked
into the public API, so it woud be extremely difficult to change.

A 2.x BeanUtils would have the opportunity to resolve this (plus apply
a lot of the other lessons we've learned over the last four years).

> 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.

> 
> Regards,
> 
> Simon
> 

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message