commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@apache.org>
Subject Re: [digester] TO-DO for release 1.6
Date Thu, 15 Apr 2004 00:40:13 GMT
robert burrell donkin wrote:

> On 13 Apr 2004, at 03:19, Simon Kitching wrote:
>
> <snip>
>
> (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.
>
>
> +1
>
> using jdiff is probably a good way to kick the process off.
>
Definitely +1.

>> ===
>> 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.
>
We should be good to go with either ... even in [beanutils] the only 
dependency is on things that I don't think have changed.  We still have 
to test, of roucrse.

>> ===
>> 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.
>
In a lot of code with the 1.x license, there was an "$Id$" line right at 
the top of the license comments, which I personaly found very convenient 
:-).

>> 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...
>
>
> +1
>
I will look at the proposal, and wouldn't mind the changes if they look 
solid, but don't feel a burning desire for them myself.

> once you know how to cut releases, let's quickly resolve this one and 
> cut another release.
>
One additional issue was raised a while ago on the mailing list, and 
again with me in personal mail; we ship the DTDs for the RSS formats 
inside commons-digester.jar, but they have Netscape copyrights.  
Although  the precedent of allowing DTDs with non-Apache copyrights has 
been established elsewhere (W3C copyrights on some of the web services 
DTDs), I don't think we really need to ship the RSS stuff inside our JAR 
-- it's just a demo, after all.

There was talk at one time about moving the RSS stuff out into a 
src/examples directory, and packaging it in a separate JAR, but this 
hasn't been done yet.  Anyone have a problem with me doing this 
(probably late tonight)?


> - robert
>

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