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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
