commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: Pool 2.4 jar SNAFU is possible for all components
Date Sat, 30 May 2015 20:51:26 GMT
On 5/30/15 1:16 PM, Gary Gregory wrote:
> I am wondering if we need an updated build process here.
>
> At work, in a large Ant based project, we run unit tests against the jars
> files built earlier by the build. We ship jars, not class files, so we test
> jars.
>
> It seems like a basic design failing in Maven or the way we use Maven.
>
> Is it possible to set up Maven to run tests against the built jar?

I think its best to test applications that use the jar.  Sadly, I in
fact did that with pre-RC versions of the pool 2.4 jar; but I just
used mvn package to create the jar I used for testing.  My bad for
not testing the actual RC jar.  I will certainly never do things in
that order again.

In the early days of m1 when it was really unreliable, I used to
maintain an Ant script for [math] that did exactly what your are
suggesting.  I vaguely recall using it as sort of a poor man's Clirr
as well - compiling and running the last version's test sources
against the next version's jar.  Good idea to add such a script to
[pool] with [dbcp] tests as sources.  And for other components, just
using the test sources for that component.  Easy to do in Ant.  Not
so sure about maven.

Another thing I always do is explode RC jars and look at the
manifest.  I am very disappointed that when I did this, I did not
notice the coberta.properties file extraneously added to the 2.4 jar
contents.

Bottom line is the RM is responsible for validating release contents
and I did not perform sufficient validation in this case.  That will
not happen again.

In terms of improving the build process, this nightmare has added to
my zeal to rid the software build of site-related cruft.  We don't
distribute the web site.  I would be big +1 to stop generating site
builds as part of the RC process.  I may just start doing that in
any case.

Phil
>
> Gary
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message