commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <si...@ecnetwork.co.nz>
Subject Re: [digester] dependencies for 1.6 release
Date Mon, 26 Jul 2004 03:45:31 GMT
On Mon, 2004-07-26 at 15:23, Craig McClanahan wrote:
> > 
> > For me, the most important decision is whether to roll back Craig
> > McClanahan's changes to the ArrayStack class. Craig added a copy of
> > ArrayStack as o.a.c.d.ArrayStack, to remove the dependency on
> > commons-collections. But this creates a binary compatibility; because
> > the field is protected, any existing code that subclasses Digester will
> > break.
> > 
> 
> Ah ... that's the rationale that I hadn't caught in the earlier thread
> ... and it makes perfect sense.  The problem was that the package name
> was changed when I did the import, and that's the wrong thing to do. 
> Robert did it right when he copied o.a.c.c.ArrayStack into beanutils
> ... the package name is still "collections".
> 
> > If containers exist which expose the Digester to the containees, then we
> > probably do need to roll back this change. But I'm not convinced this is
> > the case.
> > 
> > The other significant issue is whether to require the new BeanUtils
> > release for Digester.
> > 
> > I'm currently
> >   +1 on leaving Craig's changes in (-0 on removing them)
> >   +1 on requiring the latest BeanUtils.
> 
> If we pull this change back out, and go back to
> org.apache.commons.collections.ArrayStack, then the new Digester
> should work with either
> (a) old BeanUtils and old Collections, or
> (b) new BeanUtils
> 
> So, I'm currently:
> +1 on pulling this change out
> +1 on requiring new BeanUtils (and removing the
>     explicit Collections dependency).
> 
> If someone wants to test the old-beanutils+collections scenario, we
> can document that combination as working as well.

But this concept of bundling o.a.c.collections classes with an
o.a.c.digester distribution isn't stable long-term, right? It is only a
short-term hack to preserve backwards compatibility for a short while
until a better solution is implemented. It creates *really* nasty
problems if an app ever wants to use a release of o.a.c.collections
which has a modified ArrayStack class. And it's just not elegant.

The situation with BeanUtils is slightly different, due to the public
API which references collections; but even then, its not so different. A
protected field is part of the published API to a class too.

I believe the better (long-term) solution is to create
o.a.c.d.ArrayStack, just as Craig has done. Digester can then be used
without collections, and any version of collections can then be safely
used in the same classloader as Digester if someone desires it.
BeanUtils will then effectively do the same, resulting in a small amount
of code duplication, but with each app's dependencies being much
cleaner.

What exactly is this ugly hack of bundling o.a.c.c.ArrayStack with
o.a.c.beanutils giving us? What is the plan for phasing out
o.a.c.c.ArrayStack in favour of o.a.c.d.ArrayStack?

I can't currently see any real benefit in delaying implementing the
proper solution. Yes, the change to o.a.c.d.ArrayStack is
binary-incompatible. But as I said earlier, this is not a *bugfix*
release (third-digit version change), but a *feature* release
(second-digit version change), except for a fix to NodeCreateRule.
No-one *has* to upgrade to the latest digester release. If someone
chooses to upgrade, then they should recompile against the latest
release, and then the problem goes away.

The container/containee relationship is the only case I can see where it
is not feasable to recompile against the new release; the distributor of
the container can't recompile the containees, and in many cases neither
can the sysop deploying the container. But as we've established, sane
containers don't expose their use of Digester to the containees, so that
argument is not valid.

Regards,

Simon


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


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