commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <>
Subject Re: [VOTE] Release Validator 1.3.0 based on RC2
Date Mon, 20 Mar 2006 03:03:17 GMT
Rahul, Henri, thanks for the feedback - comments inline.

On 3/18/06, Henri Yandell <> wrote:
> On 3/17/06, Rahul Akolkar <> wrote:
> > On 3/17/06, Niall Pemberton <> wrote:
> > > I have just uploaded release candidate 2 (RC2) for Commons Validator 1.3.0.
> > > The main differences from RC1 was to remove further references to the
> > > cancelled 1.2.1 version..
> > >
> > <snip/>
> >
> > Source tarball builds / sites.
> Yep. Builds (lots of error noise, but trunk makes the same noise).

The "exception" test was working fine, but the stack traces for the
"runtime" exceptions were showing in the output which made it look
like their were problems. Anyway, the tests are pretty pointless for
Validator 1.x and since the planned exception handling changes never
took place, I've commented them out. With a couple of other changes I
made there should be much less "noise".

> Dist builds. Various errors on the way (jsdoc fails, svn fails) but it
> suceeds as a job-wise (takes forever :) [8 minutes] ).

Maven runs the tests four times - the additional three times because
of  the jdepend, junit and jcoverage plugins. I've removed the jdepend
plugin. The other reason it takes so long is the UrlTest takes about
30 seconds (and its repeated). At some point I'll try to take a look
at refactoring this test, but it'll have to wait till after the

> > Couple of comments:
> >  * md5s do not verify.
> >  * no sigs available to verify.
> >
> > Can someone please confirm / refute my md5 observations?
> Confirmed:
> ERROR: Checksum stored in does
> not match
> Correct hash:  945b7f27b34006259405a086587b8de5
> File contents: 99b24844a16e59734a06dd2fa0d11c30
> All of the md5 files have the same contents - so definitely a problem there.

Good catch, thanks. All the "checksum" tasks used the same property
name, but it appears that if the property already has a value it
doesn't overwrite it. I've changed the maven build so that each one
uses a property with a unique name and it seems to have sorted out the
problem. This means I need to cut a new RC.

> Need sigs - and pointer to the KEYS file to use them with.

I didn't think we needed to do these until a RC was approved and the
actual release was cut. I'll do them for the next RC though if thats
whats required.

> Should we be worried that the trunk of validator failed its gump
> build? Works fine for me locally using Maven, but the Ant one requires
> setting up N variables and after years of Maven I just hate having to
> do that.

The gump failure was because I changed the ant build to create a jar
which included the version number (as the maven build does) - this
screwed up what gump was expecting, but Bill Barker sorted it out in

I have changed the ant build to automatically download dependencies so
in the next RC it should work without having to set up N variables.


> Hen

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

View raw message