commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Pool 2.4 jar SNAFU is possible for all components
Date Sun, 31 May 2015 16:45:45 GMT
On 30 May 2015 at 22:10, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 5/30/15 2:00 PM, Gary Gregory wrote:
>> On Sat, May 30, 2015 at 1:51 PM, Phil Steitz <phil.steitz@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.
>
> The actual release is what we push to the ASF mirrors.  I do not
> want to see us "skip" that or to say that non-ASF infrastructure is
> the canonical location for people to get our release source
> distributions.
>
> The manual part most irritating to me is having to delete all of the
> extra files from Nexus.  Multi-select would be really nice :)

Better would be if Maven did not generate the useless hashes in the first place.
There have been several bug reports on this problem, the latest:
https://issues.apache.org/jira/browse/MNG-5504
suggests that the problem has been fixed in Maven 3.3.1
I've not tried this version yet.

If you don't mind the mess in the staging directory and in Maven
Central, just leave the extra files in place. [AIUI MC don't care if
they are uploaded]

I find them a big nuisance when reviewing the directory contents so I
delete them.

> Adding integration tests is a good idea.  I will look into Thomas'
> suggestion and / or dusting off my old Ant scripts.
>
> Phil
>>
>> 2c,
>> Gary
>>
>>
>>> Phil
>>>> Gary
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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


Mime
View raw message