On Sat, May 30, 2015 at 1:51 PM, Phil Steitz <phil.ste...@gmail.com> wrote:
> 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. > Generating the site for an RC is not a requirement but it sure is nice. I really like being able to poke around the site if I am not at my PC. I can use my phone where ever I am to start getting a feel for an RC with reports like RAT, Clirr, FindBugs and Checkstyle. I also would not want to create a release for which a site cannot be generated because of some omission or bug or whatnot. As a user, I'd like to know that starting from sources, I can build everything clean (including the site), then start patching. Our release process is sadly painful IMO but I do not see how to change that easily. My suggestion either replaces one way of testing with another, or adds another manual step (blech). Since in theory we only release sources, I would like to only release to Maven Central and skip our own binary dist. I'm not sure if that is sacrilege but it would at least start to simplify things. 2c, Gary > Phil > > > > Gary > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
