commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [digester] TO-DO for release 1.6
Date Wed, 14 Apr 2004 20:15:37 GMT
On 13 Apr 2004, at 03:19, Simon Kitching wrote:


(mixed content in separate thread)

> ===
> Re: double-check new method signatures
> We should check that parameters and return values for all new methods
> use the most abstract-possible types, eg return Map not HashMap where
> appropriate, in order to avoid "lock-in" of concrete types. This also
> applies to declared types for any protected class members.


using jdiff is probably a good way to kick the process off.

> ===
> Re: confirm collections version compatibility
> It looks like the next digester release will still depend on
> beanutils-1.6.1. However, I am not sure whether that means that 
> digester
> can be used with collections-3.0 or not. I suggest we run beanutils
> 1.6.1 tests with the collections-3.0 library, and also run the Digester
> tests with beanutils 1.6.1 + collections 3.0. If all tests pass, then 
> we
> can declare that digester is compatible with both collections-2.1 and
> collections-3.0, right?

that sounds like a good plan. i suspect that (after craig's changes), 
there's a change that we'll be ok. it's a real shame that we made that 
mistake in the beanutils interface. decoupling from collections could 
be a real reason for pushing towards a beanutils 2.0 release.

> ===
> Re: version info
> Craig wants last-committed date and perhaps some other info in the
> source files, for "disconnected" use. But maybe this does not need to 
> be
> in the javadoc? Would the same info in a non-javadoc comment meet the
> requirements, eg like this?
>   /**
>    * class docs...
>    */
>   // last change: $.....$
>   public class ..... {
> This would remove what seems to me to be pointless info from the
> javadoc, but still allow disconnected developers to see the last commit
> info.

i'm happy with this plan but i'd say that the most usual place for this 
is at the top of the file just above (or below) the license. good since 
tags would be nice.

> Re: InvokeMethodRule ("call method as soon as params are available")
> I'm quite happy for this to wait until next release for consideration.
> However, Emmanuel Bourg has requested this feature. And it may also be
> useful for providing "immutable object support" in betwixt. So if 
> anyone
> out there feels strongly about including this feature in 1.6, then they
> had better check out my proposal, and either approve it or propose
> fixes/alternatives...


once you know how to cut releases, let's quickly resolve this one and 
cut another release.

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message