Hi,
Here's the list of things I think are remaining to do before a 1.6
release. I notice that the 1.5 release was done on 24-april-2003.
Wouldn't it be nice to get another release out before the year is up?
If there's anything that's not on this list, please speak up!
* resolve the "mixed content" issue [see later]
* prepare release notes
I'm willing to do this if someone can give me some hints on the
most efficient way to do this...
* double-check new method signatures [see later]
* confirm collections version compatibility [see later]
* add cvs-version info in somehow [see later]
* create and commit an xmlrules example to the examples directory.
* move rss stuff to "extras" directory
* test that all examples compile & run.
* find someone willing to be official release manager
* think about including proposed InvokeMethodRule [see later]
* prepare RC candidate, test, etc.
===
Re "mixed content":
* Justin, could you please post your proposed implementation either
on this list, or attached to the bugzilla entry? Or have a look
at my proposal and indicate whether that works for you?
* Craig, you were going to have a look at this, I believe? All
comments welcome...
* Robert, you said in an email: "i have some possible concerns but i'll
need to go through the proposed code". Can you spell out these
concerns?
I'd be happy with a compromise on this feature. As the change has been
committed to keep a stack of matched rules, I *believe* that digester
subclasses can now override the startElement method to provide exactly
what my patch does. So maybe we can just document this approach
somewhere (eg by creating code in the examples subdir). I'll try to
implement this approach soon, and post the code if successful.
I think it would be nice in the long-term to provide "mixed content"
support without subclassing digester, but for now the subclassing seems
a reasonable solution.
Any opinions?
===
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.
===
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?
===
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.
===
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...
Phew!
No, really it doesn't look that bad. Only a couple of evenings' work, it
looks like to me, provided y'all are happy with this.
Craig, would you be willing to be the "official" release manager, ie
call the final release vote, sign the RC and final releases, etc.? If
not, is there someone you can blackmail into doing it??
And of course the more willing workers the better :-).
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
