You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2015/05/30 22:16:55 UTC
Pool 2.4 jar SNAFU is possible for all components
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?
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: Pool 2.4 jar SNAFU is possible for all components
Posted by sebb <se...@gmail.com>.
On 30 May 2015 at 22:10, Phil Steitz <ph...@gmail.com> wrote:
> On 5/30/15 2:00 PM, Gary Gregory wrote:
>> On Sat, May 30, 2015 at 1:51 PM, Phil Steitz <ph...@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
Re: Pool 2.4 jar SNAFU is possible for all components
Posted by Phil Steitz <ph...@gmail.com>.
On 5/30/15 2:00 PM, Gary Gregory wrote:
> On Sat, May 30, 2015 at 1:51 PM, Phil Steitz <ph...@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 :)
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
Re: Pool 2.4 jar SNAFU is possible for all components
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, May 30, 2015 at 1:51 PM, Phil Steitz <ph...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: Pool 2.4 jar SNAFU is possible for all components
Posted by Phil Steitz <ph...@gmail.com>.
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
Re: Pool 2.4 jar SNAFU is possible for all components
Posted by James Carman <ja...@carmanconsulting.com>.
When I was at ApacheCon this year I ran into Brian Fox and asked if he
might be able to help straighten out our build and release process. Perhaps
now is the perfect time for us to finally let an expert get us whipped into
shape?
On Sat, May 30, 2015 at 4:18 PM Gary Gregory <ga...@gmail.com> 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?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
>
Re: Pool 2.4 jar SNAFU is possible for all components
Posted by Thomas Neidhart <th...@gmail.com>.
On 05/30/2015 10: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?
take a look at commons-logging, which uses the failsafe plugin to run
integration tests using the packaged jar.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org