On 11/10/06, Simon Kitching <[EMAIL PROTECTED]> wrote:
Hi Rahul,
On Thu, 2006-11-09 at 13:44 -0500, Rahul Akolkar wrote:
<snip/>
>
> 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).
<snap/>
Thanks, that matches my understanding.
Unfortunately maven has no way of expressing this either/or dependency,
so we have to choose one or the other.
<snip/>
Given that Digester doesn't have a direct dependency (and given that
there was some effort in BeanUtils 1.7 towards making this possible),
then truth in advertising demands that the option we choose is
BeanUtils 1.7.
Separately, I'd claim that upgrading BeanUtils because a newer release
is available is also good.
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?
<snap/>
Once we go down the depedency exclusion route (and it is likely that
largish projects will), no one is out of luck (in theory, should be
able to exclude the transitive b-1.7 and explicitly declare
b-1.6+collections).
On the other hand, declaring both deps makes everyone's app larger than
it needs to be if they don't otherwise need collections.
<snip/>
Correct, I've been using digester without collections ever since d-1.7.
>
> 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!
<snap/>
OK (I have a TODO to try out cross JVM serialization round trips without UIDs).
> 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.
<snip/>
Works, I'll look once I get back (out for a conference till Wed).
-Rahul
Otherwise I think things are pretty good to go.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
