Hi Rahul,

On Thu, 2006-11-09 at 13:44 -0500, Rahul Akolkar wrote:
> > On 9/25/06, Simon Kitching (JIRA) <[EMAIL PROTECTED]> wrote:
> <snip/>
> >
> > > It's probably a good time; a couple of minor bugfixes/enhancements have 
> > > been made that deserve release (see RELEASE-NOTES.txt).
> > >
> <snap/>
> 
> Coming back to this thread, couple of quick comments before we hit an
> RC (no rush, but wanted to get to this before a RC was cut):
> 
> a) Lets wean digester off of collections (and upgrade beanutils to 1.7)

Not sure.

If you're talking about the dependency declarations in the pom.xml, it's
the way it is at the moment because I just based the maven2 pom on the
maven1 stuff; I'm more focused at the moment on getting the maven2 build
working than updating the maven1 stuff.

Historical note:
Digester doesn't have a dependency on Collections directly.
Unfortunately, Digester does need Beanutils, and Beanutils has a
collections class in its public API. What Robert Donkin did in the 1.7
release of Beanutils was bundle the necessary collections class in the
Beanutils library. It's a little ugly but it was a very stable class and
breaks the dependency from BeanUtils on Collections. That's why the
release notes state that Digester's dependency is *either* beanutils1.6
+ collections or beanutils1.7 (no collections).

Unfortunately maven has no way of expressing this either/or dependency,
so we have to choose one or the other. 

If we go for the beanutils1.7 option, then people wanting to use
Digester in an app that needs beanutils 1.6 are out of luck. However if
we leave things as they are (collections+beanutils) they can just use a
maven2 dependency exclusion to suppress the collections dependency and
all will be well, no?

On the other hand, declaring both deps makes everyone's app larger than
it needs to be if they don't otherwise need collections.

> 
> b) We're missing a few serial version UIDs (adding those might
> unnecessarily break some serialization contracts though)

I would lean towards adding the UID on any class we change, and leaving
it alone on anything we haven't modified. I'll look to see if any of the
classes changed since 1.7 have a missing UID. And of course we should
check that the UID on any changed class has been updated!


> WDYT?
> 
> If theres anything I can help with for the release, let me know.

If you want to get stuck in to the pom.xml file, please go ahead. What
I've committed so far is just an initial stab; there is still 1 unit
test failure when running under surefire and I haven't got to testing
the distribution step yet.

Or you could look at the UID stuff, if you agree with my comments above.

Otherwise I think things are pretty good to go.

Cheers,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to