Re: [VOTE] Release pool 2.4.1 based on RC1
On May 30, 2015, at 8:58 AM, Stefan Bodewig bode...@apache.org wrote: On 2015-05-30, Phil Steitz wrote: Built from: https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_4_RC1/ (r1682493) you mean https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_4_1_RC1/, right (an additional _1) - this also better matches the release number. Yes. Thanks for pointing that out and thanks for reviewing. Phil Votes, please. +1 no functional tests but sigs and hashes look good, surce tag builds for me and I don't see any suspicious traces of Cobertura instrumentation inside the jar. Cheers Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
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: 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
Re: [math] MATH-1229
On 5/30/15 10:26 AM, er...@apache.org wrote:
Repository: commons-math
Updated Branches:
refs/heads/master 441687e5a - 8be87e032
MATH-1229
Set initial capacity to input array's size in order to avoid
unnecessary resizing for inputs larger than than the default
capacity.
Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-math/commit/8be87e03
Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/8be87e03
Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/8be87e03
Branch: refs/heads/master
Commit: 8be87e032a8c05622148357f30bdca3c614a669f
Parents: 441687e
Author: Gilles er...@apache.org
Authored: Sat May 30 19:23:35 2015 +0200
Committer: Gilles er...@apache.org
Committed: Sat May 30 19:23:35 2015 +0200
--
.../org/apache/commons/math4/util/ResizableDoubleArray.java | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/commons-math/blob/8be87e03/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
--
diff --git
a/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
b/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
index 09fd748..f5292c4 100644
--- a/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
+++ b/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
@@ -179,7 +179,6 @@ public class ResizableDoubleArray implements DoubleArray,
Serializable {
* The input array is copied, not referenced.
* Other properties take default values:
* ul
- * li{@code initialCapacity = 16}/li
* li{@code expansionMode = MULTIPLICATIVE}/li
* li{@code expansionFactor = 2.0}/li
* li{@code contractionCriterion = 2.5}/li
@@ -189,7 +188,9 @@ public class ResizableDoubleArray implements DoubleArray,
Serializable {
* @since 2.2
*/
public ResizableDoubleArray(double[] initialArray) {
-this(DEFAULT_INITIAL_CAPACITY,
+this((initialArray == null || initialArray.length == 0 ?
+1 for the change here. Good catch. But I am wondering, might it
be better to use
initialArray.length DEFAULT_INITIAL_CAPACITY in the test above?
Phil
+ DEFAULT_INITIAL_CAPACITY :
+ initialArray.length),
DEFAULT_EXPANSION_FACTOR,
DEFAULT_CONTRACTION_DELTA + DEFAULT_EXPANSION_FACTOR,
DEFAULT_EXPANSION_MODE,
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Pool 2.4 jar SNAFU is possible for all components
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Pool 2.4 jar SNAFU is possible for all components
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 garydgreg...@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: 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
Re: Pool 2.4 jar SNAFU is possible for all components
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Pool 2.4 jar SNAFU is possible for all components
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
Re: Pool 2.4 jar SNAFU is possible for all components
On 5/30/15 2:00 PM, Gary Gregory wrote: 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. 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] MATH-1229
On Sat, 30 May 2015 13:55:56 -0700, Phil Steitz wrote:
On 5/30/15 10:26 AM, er...@apache.org wrote:
Repository: commons-math
Updated Branches:
refs/heads/master 441687e5a - 8be87e032
MATH-1229
Set initial capacity to input array's size in order to avoid
unnecessary resizing for inputs larger than than the default
capacity.
Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
Commit:
http://git-wip-us.apache.org/repos/asf/commons-math/commit/8be87e03
Tree:
http://git-wip-us.apache.org/repos/asf/commons-math/tree/8be87e03
Diff:
http://git-wip-us.apache.org/repos/asf/commons-math/diff/8be87e03
Branch: refs/heads/master
Commit: 8be87e032a8c05622148357f30bdca3c614a669f
Parents: 441687e
Author: Gilles er...@apache.org
Authored: Sat May 30 19:23:35 2015 +0200
Committer: Gilles er...@apache.org
Committed: Sat May 30 19:23:35 2015 +0200
--
.../org/apache/commons/math4/util/ResizableDoubleArray.java | 5
+++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/commons-math/blob/8be87e03/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
--
diff --git
a/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
b/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
index 09fd748..f5292c4 100644
---
a/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
+++
b/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
@@ -179,7 +179,6 @@ public class ResizableDoubleArray implements
DoubleArray, Serializable {
* The input array is copied, not referenced.
* Other properties take default values:
* ul
- * li{@code initialCapacity = 16}/li
* li{@code expansionMode = MULTIPLICATIVE}/li
* li{@code expansionFactor = 2.0}/li
* li{@code contractionCriterion = 2.5}/li
@@ -189,7 +188,9 @@ public class ResizableDoubleArray implements
DoubleArray, Serializable {
* @since 2.2
*/
public ResizableDoubleArray(double[] initialArray) {
-this(DEFAULT_INITIAL_CAPACITY,
+this((initialArray == null || initialArray.length == 0 ?
+1 for the change here. Good catch. But I am wondering, might it
be better to use
initialArray.length DEFAULT_INITIAL_CAPACITY in the test above?
It would not correspond to the documentation; and in some hypothetical
use-cases, it might not be expected (e.g. if instantiating many arrays
with sizes DEFAULT_INITIAL_CAPACITY).
Your suggestion could be useful in most actual use-cases...
Gilles
Phil
+ DEFAULT_INITIAL_CAPACITY :
+ initialArray.length),
DEFAULT_EXPANSION_FACTOR,
DEFAULT_CONTRACTION_DELTA + DEFAULT_EXPANSION_FACTOR,
DEFAULT_EXPANSION_MODE,
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[RESULT] [VOTE] Release pool 2.4.1 based on RC1
This VOTE has passed, with binding +1 votes from Luc Maisonobe Oliver Heger Stefan Bodewig Phil Steitz and no other votes. Thanks! Phil On 5/29/15 4:35 PM, Phil Steitz wrote: This is a vote to release version 2.4.1 of Apache Commons Pool based on RC1. Version 2.4.1 is source-identical to 2.4 other than build configuration (pom and findbugs filter). This release is to replace the defective binary jar created due to a build plugin bug (see POOL-297). Here is the release candidate: https://dist.apache.org/repos/dist/dev/commons/pool/ (r9171) Built from: https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_4_RC1/ (r1682493) Release notes: https://dist.apache.org/repos/dist/dev/commons/pool/RELEASE-NOTES.txt Maven artifacts: http://s.apache.org/M5m site: http://people.apache.org/~psteitz/pool/pool-2.4.1-rc1 (I will s/2.4/2.4.1 in the javadoc link post-release) keys: https://www.apache.org/dist/commons/KEYS Votes, please. This vote will close in 24 hours if there are 3 +1 votes by that time. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] MATH-1229
On 5/30/15 2:21 PM, Gilles wrote:
On Sat, 30 May 2015 13:55:56 -0700, Phil Steitz wrote:
On 5/30/15 10:26 AM, er...@apache.org wrote:
Repository: commons-math
Updated Branches:
refs/heads/master 441687e5a - 8be87e032
MATH-1229
Set initial capacity to input array's size in order to avoid
unnecessary resizing for inputs larger than than the default
capacity.
Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
Commit:
http://git-wip-us.apache.org/repos/asf/commons-math/commit/8be87e03
Tree:
http://git-wip-us.apache.org/repos/asf/commons-math/tree/8be87e03
Diff:
http://git-wip-us.apache.org/repos/asf/commons-math/diff/8be87e03
Branch: refs/heads/master
Commit: 8be87e032a8c05622148357f30bdca3c614a669f
Parents: 441687e
Author: Gilles er...@apache.org
Authored: Sat May 30 19:23:35 2015 +0200
Committer: Gilles er...@apache.org
Committed: Sat May 30 19:23:35 2015 +0200
--
.../org/apache/commons/math4/util/ResizableDoubleArray.java
| 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/commons-math/blob/8be87e03/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
--
diff --git
a/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
b/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
index 09fd748..f5292c4 100644
---
a/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
+++
b/src/main/java/org/apache/commons/math4/util/ResizableDoubleArray.java
@@ -179,7 +179,6 @@ public class ResizableDoubleArray implements
DoubleArray, Serializable {
* The input array is copied, not referenced.
* Other properties take default values:
* ul
- * li{@code initialCapacity = 16}/li
* li{@code expansionMode = MULTIPLICATIVE}/li
* li{@code expansionFactor = 2.0}/li
* li{@code contractionCriterion = 2.5}/li
@@ -189,7 +188,9 @@ public class ResizableDoubleArray implements
DoubleArray, Serializable {
* @since 2.2
*/
public ResizableDoubleArray(double[] initialArray) {
-this(DEFAULT_INITIAL_CAPACITY,
+this((initialArray == null || initialArray.length == 0 ?
+1 for the change here. Good catch. But I am wondering, might it
be better to use
initialArray.length DEFAULT_INITIAL_CAPACITY in the test above?
It would not correspond to the documentation; and in some
hypothetical
use-cases, it might not be expected (e.g. if instantiating many
arrays
with sizes DEFAULT_INITIAL_CAPACITY).
Yeah, the documentation would have to be changed to make it clear.
It's also not a big deal because the default expansion mode is
multiplicative, so the effect of too small initial capacity will go
away fairly quickly. I had not thought of the (strange but
possible) example you cite. I guess its simpler to just leave it as is.
Phil
Your suggestion could be useful in most actual use-cases...
Gilles
Phil
+ DEFAULT_INITIAL_CAPACITY :
+ initialArray.length),
DEFAULT_EXPANSION_FACTOR,
DEFAULT_CONTRACTION_DELTA + DEFAULT_EXPANSION_FACTOR,
DEFAULT_EXPANSION_MODE,
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release pool 2.4.1 based on RC1
Here is my +1 Phil On 5/29/15 4:35 PM, Phil Steitz wrote: This is a vote to release version 2.4.1 of Apache Commons Pool based on RC1. Version 2.4.1 is source-identical to 2.4 other than build configuration (pom and findbugs filter). This release is to replace the defective binary jar created due to a build plugin bug (see POOL-297). Here is the release candidate: https://dist.apache.org/repos/dist/dev/commons/pool/ (r9171) Built from: https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_4_RC1/ (r1682493) Release notes: https://dist.apache.org/repos/dist/dev/commons/pool/RELEASE-NOTES.txt Maven artifacts: http://s.apache.org/M5m site: http://people.apache.org/~psteitz/pool/pool-2.4.1-rc1 (I will s/2.4/2.4.1 in the javadoc link post-release) keys: https://www.apache.org/dist/commons/KEYS Votes, please. This vote will close in 24 hours if there are 3 +1 votes by that time. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release pool 2.4.1 based on RC1
Le 30/05/2015 01:35, Phil Steitz a écrit : This is a vote to release version 2.4.1 of Apache Commons Pool based on RC1. Version 2.4.1 is source-identical to 2.4 other than build configuration (pom and findbugs filter). This release is to replace the defective binary jar created due to a build plugin bug (see POOL-297). Here is the release candidate: https://dist.apache.org/repos/dist/dev/commons/pool/ (r9171) Built from: https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_4_RC1/ (r1682493) Release notes: https://dist.apache.org/repos/dist/dev/commons/pool/RELEASE-NOTES.txt Maven artifacts: http://s.apache.org/M5m site: http://people.apache.org/~psteitz/pool/pool-2.4.1-rc1 (I will s/2.4/2.4.1 in the javadoc link post-release) keys: https://www.apache.org/dist/commons/KEYS Votes, please. When I regenerate the site from source distribution, I get 110 CLIRR errors, but I consider they are expected (and in fact they are the reason why this release is done). These errors are related to cobertura instrumentation having been removed betwee 2.4 and 2.4.1. I just don't understand why this did not show up in http://people.apache.org/~psteitz/pool/pool-2.4.1-rc1/clirr-report.html. There is also one checkstyle error (missing header in a generated cobertura.properties file), but this should be considered a false positive as it is a generated file without any Apache IP and therefore is not expected to have an Apache header. This vote will close in 24 hours if there are 3 +1 votes by that time. [X] +1 Release these artifacts Luc [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release pool 2.4.1 based on RC1
On 30 May 2015 at 10:21, Luc Maisonobe l...@spaceroots.org wrote: Le 30/05/2015 01:35, Phil Steitz a écrit : This is a vote to release version 2.4.1 of Apache Commons Pool based on RC1. Version 2.4.1 is source-identical to 2.4 other than build configuration (pom and findbugs filter). This release is to replace the defective binary jar created due to a build plugin bug (see POOL-297). Here is the release candidate: https://dist.apache.org/repos/dist/dev/commons/pool/ (r9171) Built from: https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_4_RC1/ (r1682493) Release notes: https://dist.apache.org/repos/dist/dev/commons/pool/RELEASE-NOTES.txt Maven artifacts: http://s.apache.org/M5m site: http://people.apache.org/~psteitz/pool/pool-2.4.1-rc1 (I will s/2.4/2.4.1 in the javadoc link post-release) keys: https://www.apache.org/dist/commons/KEYS Votes, please. When I regenerate the site from source distribution, I get 110 CLIRR errors, but I consider they are expected (and in fact they are the reason why this release is done). These errors are related to cobertura instrumentation having been removed betwee 2.4 and 2.4.1. I just don't understand why this did not show up in http://people.apache.org/~psteitz/pool/pool-2.4.1-rc1/clirr-report.html. Perhaps because Phil's local Maven repo had the unadulterated version of the 2.4 jar in it? There is also one checkstyle error (missing header in a generated cobertura.properties file), but this should be considered a false positive as it is a generated file without any Apache IP and therefore is not expected to have an Apache header. This vote will close in 24 hours if there are 3 +1 votes by that time. [X] +1 Release these artifacts Luc [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
AW: [compress] JDK 9 b64 breaks bzip2 decompression
Thanks for the test.
I could confirm that with JDK 1.9-b66 (64bit) and CommonsCompress 1.9 on
Windows7 64bit.
Finished loop: 1246 different numbers here
Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 26
always the same number here
tried on several JDK versions with a maximum count of 5000 runs:
1.5.0_22-b03 -- works fine
1.6.0_43-b01 -- works fine (also faster than 1.5)
1.7.0_21-b11 -- works fine (another bit faster than 1.6)
1.8.0_31-b13 -- works fine (again a little bit faster than 1.7)
1.9.0-ea-b66 -- fail
Havent an earlier version of 1.9 on my machine. b66 had deinstalled that ;)
Jan
-Ursprüngliche Nachricht-
Von: Stefan Bodewig [mailto:bode...@apache.org]
Gesendet: Freitag, 29. Mai 2015 21:01
Cc: d...@ant.apache.org; dev@commons.apache.org; Rory O'Donnell; Dalibor
Topic; Balchandra Vaidya; Vivek Theeyarath
Betreff: Re: [compress] JDK 9 b64 breaks bzip2 decompression
I've stripped down the test case to
-
import java.io.*;
import
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStrea
m;
import org.apache.commons.compress.utils.IOUtils;
public class Bzip2DecompressorLoop {
public static void main(String[] args) throws IOException {
int loops = 0;
while (true) {
ByteArrayOutputStream devNull = new
ByteArrayOutputStream();
BZip2CompressorInputStream in = new
BZip2CompressorInputStream(new FileInputStream(bla.tar.bz2));
IOUtils.copy(in, devNull);
System.err.println(Finished loop: + (loops++));
}
}
}
-
compile it against Commons Compress 1.9 and use
https://svn.apache.org/repos/asf/commons/proper/compress/trunk/src/test
/resources/bla.txt.bz2
It's not always the same number but somewhere around loop 53 I get a
BZip2 CRC error when using JDK 9 b64 - this is after decompressing
the same file several times without any problems.
Cheers
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release pool 2.4.1 based on RC1
On 5/30/15 4:55 AM, sebb wrote: On 30 May 2015 at 10:21, Luc Maisonobe l...@spaceroots.org wrote: Le 30/05/2015 01:35, Phil Steitz a écrit : This is a vote to release version 2.4.1 of Apache Commons Pool based on RC1. Version 2.4.1 is source-identical to 2.4 other than build configuration (pom and findbugs filter). This release is to replace the defective binary jar created due to a build plugin bug (see POOL-297). Here is the release candidate: https://dist.apache.org/repos/dist/dev/commons/pool/ (r9171) Built from: https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_4_RC1/ (r1682493) Release notes: https://dist.apache.org/repos/dist/dev/commons/pool/RELEASE-NOTES.txt Maven artifacts: http://s.apache.org/M5m site: http://people.apache.org/~psteitz/pool/pool-2.4.1-rc1 (I will s/2.4/2.4.1 in the javadoc link post-release) keys: https://www.apache.org/dist/commons/KEYS Votes, please. When I regenerate the site from source distribution, I get 110 CLIRR errors, but I consider they are expected (and in fact they are the reason why this release is done). These errors are related to cobertura instrumentation having been removed betwee 2.4 and 2.4.1. I just don't understand why this did not show up in http://people.apache.org/~psteitz/pool/pool-2.4.1-rc1/clirr-report.html. Perhaps because Phil's local Maven repo had the unadulterated version of the 2.4 jar in it? Yes, that's what happened. As part of my troubleshooting, I ended up installing a clean 2.4 jar locally. I think it is best, actually, to publish the site without the extraneous Clirr stuff, or to just generate it with 2.3 as the reference version if that is possible. In any case, that should not block the urgent action of getting a clean binary release out. Phil There is also one checkstyle error (missing header in a generated cobertura.properties file), but this should be considered a false positive as it is a generated file without any Apache IP and therefore is not expected to have an Apache header. This vote will close in 24 hours if there are 3 +1 votes by that time. [X] +1 Release these artifacts Luc [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release pool 2.4.1 based on RC1
+1 Tested again build on Java 1.6 and 1.8 on Windows 8.1, artifacts, and site. As expected, I get the same clirr errors as reported by Luc and have still trouble with the ant build as for 2.4. Oliver Am 30.05.2015 um 01:35 schrieb Phil Steitz: This is a vote to release version 2.4.1 of Apache Commons Pool based on RC1. Version 2.4.1 is source-identical to 2.4 other than build configuration (pom and findbugs filter). This release is to replace the defective binary jar created due to a build plugin bug (see POOL-297). Here is the release candidate: https://dist.apache.org/repos/dist/dev/commons/pool/ (r9171) Built from: https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_4_RC1/ (r1682493) Release notes: https://dist.apache.org/repos/dist/dev/commons/pool/RELEASE-NOTES.txt Maven artifacts: http://s.apache.org/M5m site: http://people.apache.org/~psteitz/pool/pool-2.4.1-rc1 (I will s/2.4/2.4.1 in the javadoc link post-release) keys: https://www.apache.org/dist/commons/KEYS Votes, please. This vote will close in 24 hours if there are 3 +1 votes by that time. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release pool 2.4.1 based on RC1
On 5/30/15 8:13 AM, Oliver Heger wrote: +1 Tested again build on Java 1.6 and 1.8 on Windows 8.1, artifacts, and site. As expected, I get the same clirr errors as reported by Luc and have still trouble with the ant build as for 2.4. Thanks! I chose not to fix the ant build because I actually think its better to reference the more recent jar. It may be better to eventually reengineer the ant build to explicitly download the dependencies. Phil Oliver Am 30.05.2015 um 01:35 schrieb Phil Steitz: This is a vote to release version 2.4.1 of Apache Commons Pool based on RC1. Version 2.4.1 is source-identical to 2.4 other than build configuration (pom and findbugs filter). This release is to replace the defective binary jar created due to a build plugin bug (see POOL-297). Here is the release candidate: https://dist.apache.org/repos/dist/dev/commons/pool/ (r9171) Built from: https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_4_RC1/ (r1682493) Release notes: https://dist.apache.org/repos/dist/dev/commons/pool/RELEASE-NOTES.txt Maven artifacts: http://s.apache.org/M5m site: http://people.apache.org/~psteitz/pool/pool-2.4.1-rc1 (I will s/2.4/2.4.1 in the javadoc link post-release) keys: https://www.apache.org/dist/commons/KEYS Votes, please. This vote will close in 24 hours if there are 3 +1 votes by that time. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release pool 2.4.1 based on RC1
On 2015-05-30, Phil Steitz wrote: Built from: https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_4_RC1/ (r1682493) you mean https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_2_4_1_RC1/, right (an additional _1) - this also better matches the release number. Votes, please. +1 no functional tests but sigs and hashes look good, surce tag builds for me and I don't see any suspicious traces of Cobertura instrumentation inside the jar. Cheers Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
