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