On Fri, 2004-07-23 at 10:09, robert burrell donkin wrote: > On 22 Jul 2004, at 01:27, Simon Kitching wrote: > > On Thu, 2004-07-22 at 08:54, robert burrell donkin wrote: > > <snip> > > >> one important issue are the dependencies: in particular, disposing > >> with > >> the commons collection dependency (which prevents compatibility with > >> both 2.x and 3.x). > >> > >> i can see two possibilities: either we upgrade the beanutils > >> dependency > >> to the latest release (which contains the collections classes that > >> digester depends on) or we keep the current beanutils dependency and > >> add the necessary classes (as a temporary measure until the > >> appropriate > >> methods are deprecated). > >> > >> originally, i'd assumed that we'd automatically just upgrade the > >> beanutils dependency but (previously) stephen made some good arguments > >> for added the classes where necessary. anyone else have any opinions? > > > > Do you have a reference to Stephen's arguments? > > not to hand. > > > I'm not generally a great supporter of binary compatibility. I think if > > you intend to ship a new release of a library, then you really need a > > testing cycle. And if you're doing that, a recompile is no big deal. > > i see binary compatibility as absolutely crucial for deep libraries > such as digester. digester is in the root classpath of many containers. > this means that contained applications can only use binary compatible > versions of the library (unless they plan to recompile the application, > that is). so, releasing a binary incompatible version of digester is > likely to cause real pain for many users.
Ok, the container issue is one I overlooked. This java library versioning problem is looking nastier and nastier the more I learn about it. Maybe .NET got it right with its versioned library schema, and Java needs to adopt something like that... > > in fact, for digester two, it might be better to use a different > package name (digester2, say) to ensure that the two versions of the > library can be used together in the same container without causing > compatibility problems. I see your point. > > > Unless we roll back Craig McClanahan's changes to use a local > > ArrayStack > > implementation, we have binary incompatibilities between Digester 1.5 > > and 1.6 anyway (as described in the current release notes). > > my plan is to roll back craig's changes (on the release branch) and > ship with either the new beanutils dependency (containing the classes > digester depends on) or to ship with copies of the collection packaged > classes we need (as beanutils does). > > > So I'm currently in favour of upgrading the BeanUtils dependency. > > However I'd like to read Stephen's arguments.... > > i don't have an url to hand but the general point is that by shipping > the classes in the collections package we need (as part of the digester > jar) we maximize the choice of dependencies since this would allow > users to use digester with previous beanutils releases. At this point, I'm completely lost. The problem just seems intractible to me. We can't keep binary compatibility forever, without crushing all innovation. But shipping binary-incompatible releases of libs in container environments will, apparently, cause major pains to users of those containers. I might just move to Mono :-( In the meantime, I'm ok with whatever you decide on this. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
