Re: [pool] test failures

[Rob Tompkins]

> On Nov 19, 2018, at 5:27 PM, Gary Gregory  wrote:
> 
> HI all:
> 
> When I run 'mvn clean verify' on git master, I get test failures on my
> rather busy CPU (~60-90%):
> 
> [INFO] Running org.apache.commons.pool2.impl.TestGenericKeyedObjectPool
> [ERROR] Tests run: 63, Failures: 2, Errors: 0, Skipped: 0, Time elapsed:
> 177.53 s <<< FAILURE! - in
> org.apache.commons.pool2.impl.TestGenericKeyedObjectPool
> [ERROR]
> testEviction2(org.apache.commons.pool2.impl.TestGenericKeyedObjectPool)
> Time elapsed: 15.04 s  <<< FAILURE!
> java.lang.AssertionError: Should be less than 900 idle, found 962
>at
> org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.testEviction2(TestGenericKeyedObjectPool.java:519)
> 
> [ERROR]
> testMinIdleMaxTotalPerKey(org.apache.commons.pool2.impl.TestGenericKeyedObjectPool)
> Time elapsed: 0.705 s  <<< FAILURE!
> java.lang.AssertionError: Should be 5 idle, found 3
>at
> org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.testMinIdleMaxTotalPerKey(TestGenericKeyedObjectPool.java:672)
> 
> Does anyone see this as well?

What are your memory settings? I definitely run into tests that sit for quite a 
while.

-Rob

> 
> Gary

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

Re: [pool] test failures

[Eitan Adler]

On Mon, 19 Nov 2018 at 14:27, Gary Gregory  wrote:
>
> HI all:
>
> When I run 'mvn clean verify' on git master, I get test failures on my
> rather busy CPU (~60-90%):
>

I can not replicate
∴java -version
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)

∴uname -rms
Darwin 18.2.0 x86_64



--
Eitan Adler

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

[GitHub] commons-io pull request #69: refactor similar test cases

[yannickzj]

GitHub user yannickzj opened a pull request:

https://github.com/apache/commons-io/pull/69

refactor similar test cases

Hi!

As part of our research, we have developed a tool to suggest refactorings 
for test cases that appear to be similar. For Common-IO, it suggested these 
refactorings. We believe that they can improve test maintainability going 
forward and hope that you will accept this pull request. Please contact me or 
Patrick Lam  if you have any questions.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/yannickzj/commons-io testRF

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-io/pull/69.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #69


commit f7ed9090b8764fa4f67995b3519c0987fc2ce4a2
Author: yannickzj 
Date:   2018-11-19T23:40:49Z

refactoring suggestions for test clones




---

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

[GitHub] commons-pool pull request #18: NO-JIRA: Fix failing rat check

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-pool/pull/18


---

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

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Gary Gregory]

On Mon, Nov 19, 2018 at 2:48 PM Phil Steitz  wrote:

> Sorry ENOTIME, but I remembered that there is a nullsafe
> addIdleObject (see how addObject does it).  In fact, you might just
> replace the manual create and add with just a call to addObject
> itself.  That will also passivate the object before putting it into
> the pool, which is IIRC an invariant (objects put into the idle pool
> are passivated first).
>
> If you want to see the current code blow up, you will have to
> arrange a test with lots of borrows and returns mixed with destroys
> on validate and hope you can get the if test to succeed and then a
> return/borrow sequence before the create.
>

Like this then:

diff --git
a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
index 0575f7e..6d81dbc 100644
--- a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
+++ b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
@@ -920,8 +920,7 @@
 // In case there are already threads waiting on something in
the pool
 // (e.g. idleObjects.takeFirst(); then we need to provide them
a fresh instance.
 // Otherwise they will be stuck forever (or until timeout)
-PooledObject freshPooled = create();
-idleObjects.put(freshPooled);
+addObject();
 }
 }

But causes a failure:

[INFO] Running org.apache.commons.pool2.impl.TestAbandonedObjectPool
[ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
12.253 s <<< FAILURE! - in
org.apache.commons.pool2.impl.TestAbandonedObjectPool
[ERROR]
testAbandonedInvalidate(org.apache.commons.pool2.impl.TestAbandonedObjectPool)
Time elapsed: 3.668 s  <<< FAILURE!
java.lang.AssertionError: expected:<5> but was:<4>
at
org.apache.commons.pool2.impl.TestAbandonedObjectPool.testAbandonedInvalidate(TestAbandonedObjectPool.java:202)

Maybe this is due to my busy CPU, not sure.

Gary


>
> Phil
>
> On 11/19/18 2:31 PM, Gary Gregory wrote:
> > A unit test? Yes please! :-)
> >
> > Gary
> >
> > On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg  >
> > wrote:
> >
> >> +1 for the null check.
> >>
> >> Do you want to re-open the ticket and create a patch?
> >>
> >> I've created a unit test which proves my original problem with the
> >> dead-lock.
> >> So any improvement should be rather on the safe side from here on.
> >>
> >>
> >> Regarding the RC: this is really not needed anymore when working with
> GIT
> >> as nothing gets pushed/released to the main repository! See the config
> >> changes I did to the maven-release-plugin.
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >>
> >>
> >>> Am 19.11.2018 um 16:43 schrieb Phil Steitz :
> >>>
> >>> On 11/19/18 8:19 AM, Gary Gregory wrote:
>  On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins 
> >> wrote:
> > I’d be happy to roll the release if we get master to where you want
> >> it.
>  IMO, we should integrate the recent PR I mentioned and roll RC3. Note
> >> that this vote subject thread did not contain an RC number. Sticking to
> the
> >> usual process would be less troublesome IMO.
> >>> I have not had a chance to fully review and am not really active in
> >> [pool] any more, but I did notice that the fix for POOL-356 is missing a
> >> null check between these two added statements:
> >>>   PooledObject freshPooled = create();
> >>> idleObjects.put(freshPooled);
> >>>
> >>> create() can return null and while in general it won't in this
> >> activation context, given the lack of sync control, it is possible that
> a
> >> return hits between the if test and execution resulting in no capacity
> to
> >> create.
> >>> I also notice some system.outs made it into the test code in one of the
> >> commits related to POOL-340.
> >>> Phil
>  Gary
> 
> 
> > Cheers,
> > -Rob
> >
> >> On Nov 19, 2018, at 7:18 AM, Mark Struberg
>  > wrote:
> >> Oki, I now see what you mean.
> >>
> >> We actually have 3 source zips now.
> >>
> >> .src.zip
> >> .source-release.zip
> >> src.jar
> >>
> >> That's a mess.
> >>
> >> There should only be 2:
> >> * source-release.zip is the official ASF packages whole build
> sources.
> > This includes the pom, build structure etc.
> >> * src.jar is the sources which are automatically downloaded by the
> >> IDEs
> > for debugging purpose.
> >> We have both of them because commons-pool2 is a single-module
> project.
> >> And yes, we need both of them. What we do not need is the src.zip. I
> > have no clue yet where this comes from but it shouldn't be here.
> >> The good news:
> >> By leveraging native GIT we now can simply a.) drop the maven
> stating
> > repo in repository.a.o and b.) drop the release branch and tag from
> my
> > github account and re-roll the release without any weird RC hacks.
> >> Will do that,
> >> * fix the maven setup

[pool] test failures

[Gary Gregory]

HI all:

When I run 'mvn clean verify' on git master, I get test failures on my
rather busy CPU (~60-90%):

[INFO] Running org.apache.commons.pool2.impl.TestGenericKeyedObjectPool
[ERROR] Tests run: 63, Failures: 2, Errors: 0, Skipped: 0, Time elapsed:
177.53 s <<< FAILURE! - in
org.apache.commons.pool2.impl.TestGenericKeyedObjectPool
[ERROR]
testEviction2(org.apache.commons.pool2.impl.TestGenericKeyedObjectPool)
Time elapsed: 15.04 s  <<< FAILURE!
java.lang.AssertionError: Should be less than 900 idle, found 962
at
org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.testEviction2(TestGenericKeyedObjectPool.java:519)

[ERROR]
testMinIdleMaxTotalPerKey(org.apache.commons.pool2.impl.TestGenericKeyedObjectPool)
Time elapsed: 0.705 s  <<< FAILURE!
java.lang.AssertionError: Should be 5 idle, found 3
at
org.apache.commons.pool2.impl.TestGenericKeyedObjectPool.testMinIdleMaxTotalPerKey(TestGenericKeyedObjectPool.java:672)

Does anyone see this as well?

Gary

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Phil Steitz]

Sorry ENOTIME, but I remembered that there is a nullsafe 
addIdleObject (see how addObject does it).  In fact, you might just 
replace the manual create and add with just a call to addObject 
itself.  That will also passivate the object before putting it into 
the pool, which is IIRC an invariant (objects put into the idle pool 
are passivated first).


If you want to see the current code blow up, you will have to 
arrange a test with lots of borrows and returns mixed with destroys 
on validate and hope you can get the if test to succeed and then a 
return/borrow sequence before the create.


Phil

On 11/19/18 2:31 PM, Gary Gregory wrote:

A unit test? Yes please! :-)

Gary

On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg 
wrote:


+1 for the null check.

Do you want to re-open the ticket and create a patch?

I've created a unit test which proves my original problem with the
dead-lock.
So any improvement should be rather on the safe side from here on.


Regarding the RC: this is really not needed anymore when working with GIT
as nothing gets pushed/released to the main repository! See the config
changes I did to the maven-release-plugin.

txs and LieGrue,
strub




Am 19.11.2018 um 16:43 schrieb Phil Steitz :

On 11/19/18 8:19 AM, Gary Gregory wrote:

On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins 

wrote:

I’d be happy to roll the release if we get master to where you want

it.

IMO, we should integrate the recent PR I mentioned and roll RC3. Note

that this vote subject thread did not contain an RC number. Sticking to the
usual process would be less troublesome IMO.

I have not had a chance to fully review and am not really active in

[pool] any more, but I did notice that the fix for POOL-356 is missing a
null check between these two added statements:

  PooledObject freshPooled = create();
idleObjects.put(freshPooled);

create() can return null and while in general it won't in this

activation context, given the lack of sync control, it is possible that a
return hits between the if test and execution resulting in no capacity to
create.

I also notice some system.outs made it into the test code in one of the

commits related to POOL-340.

Phil

Gary



Cheers,
-Rob


On Nov 19, 2018, at 7:18 AM, Mark Struberg 
wrote:

Oki, I now see what you mean.

We actually have 3 source zips now.

.src.zip
.source-release.zip
src.jar

That's a mess.

There should only be 2:
* source-release.zip is the official ASF packages whole build sources.

This includes the pom, build structure etc.

* src.jar is the sources which are automatically downloaded by the

IDEs

for debugging purpose.

We have both of them because commons-pool2 is a single-module project.
And yes, we need both of them. What we do not need is the src.zip. I

have no clue yet where this comes from but it shouldn't be here.

The good news:
By leveraging native GIT we now can simply a.) drop the maven stating

repo in repository.a.o and b.) drop the release branch and tag from my
github account and re-roll the release without any weird RC hacks.

Will do that,
* fix the maven setup
* happy to also include the new ticket
* re-roll the release this afternoon.

LieGrue,
strub


Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <

rmannibu...@gmail.com>:

Le ven. 16 nov. 2018 22:54, Gary Gregory  a

écrit :

On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <

rmannibu...@gmail.com>

wrote:


Le ven. 16 nov. 2018 21:23, Gary Gregory 

a

écrit

:


On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg


wrote:


Oki, now the full VOTE text!

I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
The release was run with JDK-1.7 to ensure Java7 compatibility.


The ASF staging repository is at


https://repository.apache.org/content/repositories/orgapachecommons-1396/

The source zip is at



https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/

The sha1 of the source-release zip is
17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
The sha512 is


982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388

For me:

$ sha512sum commons-pool2-2.6.1-src.zip



2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e

*commons-pool2-2.6.1-src.zip

Which is not what you list above. Please advise.


Src vs source-release?


That's the problem with inventing a new release process... why do we

have

BOTH:




https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip

AND



https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip

And more importantly why are they _different_? Which one will be

used

in

the dist/release area?


Looks like pool didnt do its homework and kept the old assembly

(src),

sour

Re: [IO] Provenance of copied code in InfiniteCircularInputStream

[Gary Gregory]

Hi All:

I agree that the 0xff usage does not need to be documented, and while I do
see it used in ByteArrayInputStream#read() in Oracle Java 6, I really do
not think we need to refer to it.

I am +1 to removing the comment. Who will do the honors?

Gary

On Mon, Nov 19, 2018 at 10:15 AM Mark Thomas  wrote:

> I'd image the comment is referring to the use of "... & 0xFF" but it
> seems to be a fairly pointless comment as that is just the standard way
> to switch from signed byte to 'unsigned' int values.
>
> I can't see what else it could possibly be referring to.
>
> I don't see any IP issue here.
>
> I'd suggest simply removing the comment but with a fairly verbose commit
> message to help anyone looking into this in the future.
>
> Mark
>
>
> On 19/11/2018 16:57, Pascal Schumacher wrote:
> > Hi everybody,
> >
> > the code is from a pull request which I merged:
> >
> > https://github.com/apache/commons-io/pull/8
> >
> > I did not author the code.
> >
> > The comment seems incorrect because I do not think there is a field
> > "repeatedContent" in java.io.ByteArrayInputStream. The current OpenJDK
> > implementation looks pretty different:
> >
> >
> http://hg.openjdk.java.net/jdk/jdk/file/49e0f711bb2b/src/java.base/share/classes/java/io/ByteArrayInputStream.java#l146
> >
> >
> > -Pascal
> >
> > Am 19.11.2018 um 16:59 schrieb Gary Gregory:
> >> Hi All and Pascal S.,
> >>
> >> Sharon (Eclipse) has pointed out to me that
> >> in org.apache.commons.io.input.InfiniteCircularInputStream.read() [1],
> >> we have:
> >>
> >> @Override
> >> public int read() {
> >> position = (position + 1) % repeatedContent.length;
> >> return repeatedContent[position] & 0xff; // copied from
> >>  // java.io.ByteArrayInputStream.read()
> >> }
> >>
> >> Where does the code originate? Oracle JRE? OpenJDK? Where? Such a
> >> comment needs to show better provenance since I am pretty sure we are
> >> NOT allowed to copy code from Oracle.
> >>
> >> The code was added with the commit
> >>
> >>
> https://github.com/apache/commons-io/commit/699d6f0eca65837501d7ab7a92ae2c614f8e6cbf#diff-5cdd5f292c77ae5feee8f3f101ded473
> >>
> >>
> >> With this authorship:
> >>
> >> @piotrturski @PascalSchumacher
> >> 
> >> piotrturski
> >>  > authored
> >> and PascalSchumacher
> >>  > committed
> >> on Dec 1, 2015
> >>
> >> Gary
> >>
> >> [1]
> >>
> https://github.com/apache/commons-io/blob/3ad22fe3d689781a76a92908d0bbc119b2c68892/src/main/java/org/apache/commons/io/input/InfiniteCircularInputStream.java#L48-L49
> >>
> >>
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Gary Gregory]

A unit test? Yes please! :-)

Gary

On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg 
wrote:

> +1 for the null check.
>
> Do you want to re-open the ticket and create a patch?
>
> I've created a unit test which proves my original problem with the
> dead-lock.
> So any improvement should be rather on the safe side from here on.
>
>
> Regarding the RC: this is really not needed anymore when working with GIT
> as nothing gets pushed/released to the main repository! See the config
> changes I did to the maven-release-plugin.
>
> txs and LieGrue,
> strub
>
>
>
> > Am 19.11.2018 um 16:43 schrieb Phil Steitz :
> >
> > On 11/19/18 8:19 AM, Gary Gregory wrote:
> >> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins 
> wrote:
> >>> I’d be happy to roll the release if we get master to where you want
> it.
> >> IMO, we should integrate the recent PR I mentioned and roll RC3. Note
> that this vote subject thread did not contain an RC number. Sticking to the
> usual process would be less troublesome IMO.
> >
> > I have not had a chance to fully review and am not really active in
> [pool] any more, but I did notice that the fix for POOL-356 is missing a
> null check between these two added statements:
> >
> >  PooledObject freshPooled = create();
> > idleObjects.put(freshPooled);
> >
> > create() can return null and while in general it won't in this
> activation context, given the lack of sync control, it is possible that a
> return hits between the if test and execution resulting in no capacity to
> create.
> >
> > I also notice some system.outs made it into the test code in one of the
> commits related to POOL-340.
> >
> > Phil
> >>
> >> Gary
> >>
> >>
> >>> Cheers,
> >>> -Rob
> >>>
>  On Nov 19, 2018, at 7:18 AM, Mark Struberg  >
> >>> wrote:
>  Oki, I now see what you mean.
> 
>  We actually have 3 source zips now.
> 
>  .src.zip
>  .source-release.zip
>  src.jar
> 
>  That's a mess.
> 
>  There should only be 2:
>  * source-release.zip is the official ASF packages whole build sources.
> >>> This includes the pom, build structure etc.
>  * src.jar is the sources which are automatically downloaded by the
> IDEs
> >>> for debugging purpose.
>  We have both of them because commons-pool2 is a single-module project.
>  And yes, we need both of them. What we do not need is the src.zip. I
> >>> have no clue yet where this comes from but it shouldn't be here.
> 
>  The good news:
>  By leveraging native GIT we now can simply a.) drop the maven stating
> >>> repo in repository.a.o and b.) drop the release branch and tag from my
> >>> github account and re-roll the release without any weird RC hacks.
>  Will do that,
>  * fix the maven setup
>  * happy to also include the new ticket
>  * re-roll the release this afternoon.
> 
>  LieGrue,
>  strub
> 
> > Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
> >>> rmannibu...@gmail.com>:
> > Le ven. 16 nov. 2018 22:54, Gary Gregory  a
> >>> écrit :
> >> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> >>> rmannibu...@gmail.com>
> >> wrote:
> >>
> >>> Le ven. 16 nov. 2018 21:23, Gary Gregory 
> a
> >> écrit
> >>> :
> >>>
>  On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> >>   wrote:
> 
> > Oki, now the full VOTE text!
> >
> > I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> > The release was run with JDK-1.7 to ensure Java7 compatibility.
> >
> >
> > The ASF staging repository is at
> >
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> > The source zip is at
> >
> >
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > The sha1 of the source-release zip is
> > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > The sha512 is
> >
> >>>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>  For me:
> 
>  $ sha512sum commons-pool2-2.6.1-src.zip
> 
> 
> >>>
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
>  *commons-pool2-2.6.1-src.zip
> 
>  Which is not what you list above. Please advise.
> 
> >>> Src vs source-release?
> >>>
> >> That's the problem with inventing a new release process... why do we
> >>> have
> >> BOTH:
> >>
> >>
> >>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> >> AND
> >>
> >>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/co

Re: commons-compress git commit: shorten method name

[Gary Gregory]

:-)

Gary

On Mon, Nov 19, 2018 at 9:25 AM  wrote:

> Repository: commons-compress
> Updated Branches:
>   refs/heads/master f132d6c50 -> 6e47be35f
>
>
> shorten method name
>
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-compress/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/commons-compress/commit/6e47be35
> Tree:
> http://git-wip-us.apache.org/repos/asf/commons-compress/tree/6e47be35
> Diff:
> http://git-wip-us.apache.org/repos/asf/commons-compress/diff/6e47be35
>
> Branch: refs/heads/master
> Commit: 6e47be35fca595d8637441a578e29045b329c611
> Parents: f132d6c
> Author: Stefan Bodewig 
> Authored: Mon Nov 19 17:24:53 2018 +0100
> Committer: Stefan Bodewig 
> Committed: Mon Nov 19 17:24:53 2018 +0100
>
> --
>  .../compress/archivers/zip/ParallelScatterZipCreator.java| 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/commons-compress/blob/6e47be35/src/main/java/org/apache/commons/compress/archivers/zip/ParallelScatterZipCreator.java
> --
> diff --git
> a/src/main/java/org/apache/commons/compress/archivers/zip/ParallelScatterZipCreator.java
> b/src/main/java/org/apache/commons/compress/archivers/zip/ParallelScatterZipCreator.java
> index bd5a561..7e8f8ad 100644
> ---
> a/src/main/java/org/apache/commons/compress/archivers/zip/ParallelScatterZipCreator.java
> +++
> b/src/main/java/org/apache/commons/compress/archivers/zip/ParallelScatterZipCreator.java
> @@ -263,7 +263,7 @@ public class ParallelScatterZipCreator {
>
>  scatterDoneAt = System.currentTimeMillis();
>  } finally {
> -ensureStreamsAreClosed();
> +closeAll();
>  }
>  }
>
> @@ -276,7 +276,7 @@ public class ParallelScatterZipCreator {
>  return new ScatterStatistics(compressionDoneAt - startedAt,
> scatterDoneAt - compressionDoneAt);
>  }
>
> -private void ensureStreamsAreClosed() {
> +private void closeAll() {
>  synchronized (streams) {
>  for (final ScatterZipOutputStream scatterStream : streams) {
>  try {
>
>

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

+1 for the null check. 

Do you want to re-open the ticket and create a patch?

I've created a unit test which proves my original problem with the dead-lock. 
So any improvement should be rather on the safe side from here on.


Regarding the RC: this is really not needed anymore when working with GIT as 
nothing gets pushed/released to the main repository! See the config changes I 
did to the maven-release-plugin.

txs and LieGrue,
strub



> Am 19.11.2018 um 16:43 schrieb Phil Steitz :
> 
> On 11/19/18 8:19 AM, Gary Gregory wrote:
>> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins  wrote:
>>> I’d be happy to roll the release if we get master to where you want it. 
>> IMO, we should integrate the recent PR I mentioned and roll RC3. Note that 
>> this vote subject thread did not contain an RC number. Sticking to the usual 
>> process would be less troublesome IMO.
> 
> I have not had a chance to fully review and am not really active in [pool] 
> any more, but I did notice that the fix for POOL-356 is missing a null check 
> between these two added statements:
> 
>  PooledObject freshPooled = create();
> idleObjects.put(freshPooled);
> 
> create() can return null and while in general it won't in this activation 
> context, given the lack of sync control, it is possible that a return hits 
> between the if test and execution resulting in no capacity to create.
> 
> I also notice some system.outs made it into the test code in one of the 
> commits related to POOL-340.
> 
> Phil
>> 
>> Gary
>> 
>> 
>>> Cheers,
>>> -Rob
>>> 
 On Nov 19, 2018, at 7:18 AM, Mark Struberg 
>>> wrote:
 Oki, I now see what you mean.
 
 We actually have 3 source zips now.
 
 .src.zip
 .source-release.zip
 src.jar
 
 That's a mess.
 
 There should only be 2:
 * source-release.zip is the official ASF packages whole build sources.
>>> This includes the pom, build structure etc.
 * src.jar is the sources which are automatically downloaded by the IDEs
>>> for debugging purpose.
 We have both of them because commons-pool2 is a single-module project.
 And yes, we need both of them. What we do not need is the src.zip. I
>>> have no clue yet where this comes from but it shouldn't be here.
 
 The good news:
 By leveraging native GIT we now can simply a.) drop the maven stating
>>> repo in repository.a.o and b.) drop the release branch and tag from my
>>> github account and re-roll the release without any weird RC hacks.
 Will do that,
 * fix the maven setup
 * happy to also include the new ticket
 * re-roll the release this afternoon.
 
 LieGrue,
 strub
 
> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
>>> rmannibu...@gmail.com>:
> Le ven. 16 nov. 2018 22:54, Gary Gregory  a
>>> écrit :
>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
>>> rmannibu...@gmail.com>
>> wrote:
>> 
>>> Le ven. 16 nov. 2018 21:23, Gary Gregory  a
>> écrit
>>> :
>>> 
 On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>> >>> wrote:
 
> Oki, now the full VOTE text!
> 
> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> The release was run with JDK-1.7 to ensure Java7 compatibility.
> 
> 
> The ASF staging repository is at
> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> The source zip is at
> 
> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> The sha1 of the source-release zip is
> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> The sha512 is
> 
>>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
 For me:
 
 $ sha512sum commons-pool2-2.6.1-src.zip
 
 
>>> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
 *commons-pool2-2.6.1-src.zip
 
 Which is not what you list above. Please advise.
 
>>> Src vs source-release?
>>> 
>> That's the problem with inventing a new release process... why do we
>>> have
>> BOTH:
>> 
>> 
>> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
>> AND
>> 
>> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>> And more importantly why are they _different_? Which one will be used
>>> in
>> the dist/release area?
>> 
> 
> Looks like pool didnt do its homework and kept the old assembly (src),
> source-release comes from the parent and is likely the one to keep IMH

Re: [IO] Provenance of copied code in InfiniteCircularInputStream

[Mark Thomas]

I'd image the comment is referring to the use of "... & 0xFF" but it
seems to be a fairly pointless comment as that is just the standard way
to switch from signed byte to 'unsigned' int values.

I can't see what else it could possibly be referring to.

I don't see any IP issue here.

I'd suggest simply removing the comment but with a fairly verbose commit
message to help anyone looking into this in the future.

Mark


On 19/11/2018 16:57, Pascal Schumacher wrote:
> Hi everybody,
> 
> the code is from a pull request which I merged:
> 
> https://github.com/apache/commons-io/pull/8
> 
> I did not author the code.
> 
> The comment seems incorrect because I do not think there is a field
> "repeatedContent" in java.io.ByteArrayInputStream. The current OpenJDK
> implementation looks pretty different:
> 
> http://hg.openjdk.java.net/jdk/jdk/file/49e0f711bb2b/src/java.base/share/classes/java/io/ByteArrayInputStream.java#l146
> 
> 
> -Pascal
> 
> Am 19.11.2018 um 16:59 schrieb Gary Gregory:
>> Hi All and Pascal S.,
>>
>> Sharon (Eclipse) has pointed out to me that
>> in org.apache.commons.io.input.InfiniteCircularInputStream.read() [1],
>> we have:
>>
>>     @Override
>>     public int read() {
>>         position = (position + 1) % repeatedContent.length;
>>         return repeatedContent[position] & 0xff; // copied from
>>  // java.io.ByteArrayInputStream.read()
>>     }
>>
>> Where does the code originate? Oracle JRE? OpenJDK? Where? Such a
>> comment needs to show better provenance since I am pretty sure we are
>> NOT allowed to copy code from Oracle.
>>
>> The code was added with the commit
>>
>> https://github.com/apache/commons-io/commit/699d6f0eca65837501d7ab7a92ae2c614f8e6cbf#diff-5cdd5f292c77ae5feee8f3f101ded473
>>
>>
>> With this authorship:
>>
>> @piotrturski @PascalSchumacher
>> 
>> piotrturski
>>  authored
>> and PascalSchumacher
>>  
>> committed
>> on Dec 1, 2015
>>
>> Gary
>>
>> [1]
>> https://github.com/apache/commons-io/blob/3ad22fe3d689781a76a92908d0bbc119b2c68892/src/main/java/org/apache/commons/io/input/InfiniteCircularInputStream.java#L48-L49
>>
>>
> 
> 


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

Re: [IO] Provenance of copied code in InfiniteCircularInputStream

[Pascal Schumacher]

Hi everybody,

the code is from a pull request which I merged:

https://github.com/apache/commons-io/pull/8

I did not author the code.

The comment seems incorrect because I do not think there is a field 
"repeatedContent" in java.io.ByteArrayInputStream. The current OpenJDK 
implementation looks pretty different:


http://hg.openjdk.java.net/jdk/jdk/file/49e0f711bb2b/src/java.base/share/classes/java/io/ByteArrayInputStream.java#l146

-Pascal

Am 19.11.2018 um 16:59 schrieb Gary Gregory:

Hi All and Pascal S.,

Sharon (Eclipse) has pointed out to me that 
in org.apache.commons.io.input.InfiniteCircularInputStream.read() [1], 
we have:


    @Override
    public int read() {
        position = (position + 1) % repeatedContent.length;
        return repeatedContent[position] & 0xff; // copied from
 // java.io.ByteArrayInputStream.read()
    }

Where does the code originate? Oracle JRE? OpenJDK? Where? Such a 
comment needs to show better provenance since I am pretty sure we are 
NOT allowed to copy code from Oracle.


The code was added with the commit

https://github.com/apache/commons-io/commit/699d6f0eca65837501d7ab7a92ae2c614f8e6cbf#diff-5cdd5f292c77ae5feee8f3f101ded473

With this authorship:

@piotrturski @PascalSchumacher 

piotrturski 
 authored 
and PascalSchumacher 
 committed 
on Dec 1, 2015


Gary

[1] 
https://github.com/apache/commons-io/blob/3ad22fe3d689781a76a92908d0bbc119b2c68892/src/main/java/org/apache/commons/io/input/InfiniteCircularInputStream.java#L48-L49

Re: [1/3] commons-compress git commit: COMPRESS-470 make sure all ScatterZipOutputStreams are closed

[Stefan Bodewig]

On 2018-11-18, Gary Gregory wrote:

> ensureStreamsAreClosed() seems like an over the top name. Why not simply
> closeAll()? Or close().

Because I've got a track record for choosing bad names to defend :-)

Stefan

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

[GitHub] commons-pool issue #17: POOL-359: prevent NPE closing multiple GenericObject...

[graben]

Github user graben commented on the issue:

https://github.com/apache/commons-pool/pull/17
  
#18 fixes actual failing travis build!


---

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

[IO] Provenance of copied code in InfiniteCircularInputStream

[Gary Gregory]

Hi All and Pascal S.,

Sharon (Eclipse) has pointed out to me that
in org.apache.commons.io.input.InfiniteCircularInputStream.read() [1], we
have:

@Override
public int read() {
position = (position + 1) % repeatedContent.length;
return repeatedContent[position] & 0xff; // copied from
 //
java.io.ByteArrayInputStream.read()
}

Where does the code originate? Oracle JRE? OpenJDK? Where? Such a comment
needs to show better provenance since I am pretty sure we are NOT allowed
to copy code from Oracle.

The code was added with the commit

https://github.com/apache/commons-io/commit/699d6f0eca65837501d7ab7a92ae2c614f8e6cbf#diff-5cdd5f292c77ae5feee8f3f101ded473

With this authorship:

[image: @piotrturski] [image:
@PascalSchumacher] 
piotrturski
 authored
and PascalSchumacher

 committed on Dec 1, 2015

Gary

[1]
https://github.com/apache/commons-io/blob/3ad22fe3d689781a76a92908d0bbc119b2c68892/src/main/java/org/apache/commons/io/input/InfiniteCircularInputStream.java#L48-L49

[GitHub] commons-pool pull request #18: NO-JIRA: Fix failing rat check

[graben]

GitHub user graben opened a pull request:

https://github.com/apache/commons-pool/pull/18

NO-JIRA: Fix failing rat check



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/graben/commons-pool NO-JIRA

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-pool/pull/18.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #18


commit 86d4e513e15979f2a653c0f15eaf3fd38d0093eb
Author: Benjamin Graf 
Date:   2018-11-19T15:44:33Z

Fix failing rat check




---

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

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Phil Steitz]

On 11/19/18 8:19 AM, Gary Gregory wrote:
On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins  
wrote:
I’d be happy to roll the release if we get master to where you 
want it. 
IMO, we should integrate the recent PR I mentioned and roll RC3. 
Note that this vote subject thread did not contain an RC number. 
Sticking to the usual process would be less troublesome IMO.


I have not had a chance to fully review and am not really active in 
[pool] any more, but I did notice that the fix for POOL-356 is 
missing a null check between these two added statements:


 PooledObject freshPooled = create();
idleObjects.put(freshPooled);

create() can return null and while in general it won't in this 
activation context, given the lack of sync control, it is possible 
that a return hits between the if test and execution resulting in no 
capacity to create.


I also notice some system.outs made it into the test code in one of 
the commits related to POOL-340.


Phil


Gary



Cheers,
-Rob


On Nov 19, 2018, at 7:18 AM, Mark Struberg 

wrote:

Oki, I now see what you mean.

We actually have 3 source zips now.

.src.zip
.source-release.zip
src.jar

That's a mess.

There should only be 2:
* source-release.zip is the official ASF packages whole build sources.

This includes the pom, build structure etc.

* src.jar is the sources which are automatically downloaded by the IDEs

for debugging purpose.

We have both of them because commons-pool2 is a single-module project.
And yes, we need both of them. What we do not need is the src.zip. I

have no clue yet where this comes from but it shouldn't be here.


The good news:
By leveraging native GIT we now can simply a.) drop the maven stating

repo in repository.a.o and b.) drop the release branch and tag from my
github account and re-roll the release without any weird RC hacks.

Will do that,
* fix the maven setup
* happy to also include the new ticket
* re-roll the release this afternoon.

LieGrue,
strub


Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <

rmannibu...@gmail.com>:

Le ven. 16 nov. 2018 22:54, Gary Gregory  a

écrit :

On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <

rmannibu...@gmail.com>

wrote:


Le ven. 16 nov. 2018 21:23, Gary Gregory  a

écrit

:


On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg


wrote:


Oki, now the full VOTE text!

I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
The release was run with JDK-1.7 to ensure Java7 compatibility.


The ASF staging repository is at


https://repository.apache.org/content/repositories/orgapachecommons-1396/

The source zip is at



https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/

The sha1 of the source-release zip is
17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
The sha512 is


982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388

For me:

$ sha512sum commons-pool2-2.6.1-src.zip



2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e

*commons-pool2-2.6.1-src.zip

Which is not what you list above. Please advise.


Src vs source-release?


That's the problem with inventing a new release process... why do we

have

BOTH:




https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip

AND



https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip

And more importantly why are they _different_? Which one will be used

in

the dist/release area?



Looks like pool didnt do its homework and kept the old assembly (src),
source-release comes from the parent and is likely the one to keep IMHO



Gary









Gary



I added my KEY (struberg at apache.org) to our dist KEYS file
https://dist.apache.org/repos/dist/release/commons/KEYS

I've created the release in a GIT manner and pushed the according

changes

to my ASF-linked github repo

https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
the sha1 of the commit is



https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019

the tag is
https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
c910171
<

https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171

This will get pushed to the ASF cannonical repo once the VOTE

succeeds.

Site will be updated once the release has passed.

Please VOTE:

[+1] go ship it!
[+0] meh, I don't care
[-1] stop there is a ${showstopper} (that means something

_important_

is

missing!)


Here is my own +1
checked:
* signature
* hashes
* LICENSE
* NOTICE
* rat
* builds fine with various JDKs


LieGrue,
strub






Am 14.11.2018 um 10:13 schrieb Mark Struberg


:

PS: I've created the release in a GIT manner and pushed the

according

changes to my ASF-linked github repo

ht

[GitHub] commons-rng issue #14: fix: removed 1.8 annotation to ensure 1.7 compliance

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-rng/pull/14
  

[![Coverage 
Status](https://coveralls.io/builds/20181767/badge)](https://coveralls.io/builds/20181767)

Coverage remained the same at 97.544% when pulling 
**6dca4630fb4df34eb5e106dfbbe66bff271526ee on 
aherbert:fix-jmh-java-version-1.7-compliance** into 
**0fdcd9007c708aa48f1989cb2211ea56c1fcd702 on apache:master**.



---

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

[GitHub] commons-rng issue #14: fix: removed 1.8 annotation to ensure 1.7 compliance

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-rng/pull/14
  

[![Coverage 
Status](https://coveralls.io/builds/20181767/badge)](https://coveralls.io/builds/20181767)

Coverage remained the same at 97.544% when pulling 
**6dca4630fb4df34eb5e106dfbbe66bff271526ee on 
aherbert:fix-jmh-java-version-1.7-compliance** into 
**0fdcd9007c708aa48f1989cb2211ea56c1fcd702 on apache:master**.



---

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

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Gary Gregory]

On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins  wrote:

> I’d be happy to roll the release if we get master to where you want it.
>

IMO, we should integrate the recent PR I mentioned and roll RC3. Note that
this vote subject thread did not contain an RC number. Sticking to the
usual process would be less troublesome IMO.

Gary


>
> Cheers,
> -Rob
>
> > On Nov 19, 2018, at 7:18 AM, Mark Struberg 
> wrote:
> >
> > Oki, I now see what you mean.
> >
> > We actually have 3 source zips now.
> >
> > .src.zip
> > .source-release.zip
> > src.jar
> >
> > That's a mess.
> >
> > There should only be 2:
> > * source-release.zip is the official ASF packages whole build sources.
> This includes the pom, build structure etc.
> > * src.jar is the sources which are automatically downloaded by the IDEs
> for debugging purpose.
> >
> > We have both of them because commons-pool2 is a single-module project.
> > And yes, we need both of them. What we do not need is the src.zip. I
> have no clue yet where this comes from but it shouldn't be here.
> >
> >
> > The good news:
> > By leveraging native GIT we now can simply a.) drop the maven stating
> repo in repository.a.o and b.) drop the release branch and tag from my
> github account and re-roll the release without any weird RC hacks.
> >
> > Will do that,
> > * fix the maven setup
> > * happy to also include the new ticket
> > * re-roll the release this afternoon.
> >
> > LieGrue,
> > strub
> >
> >> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
> >>
> >> Le ven. 16 nov. 2018 22:54, Gary Gregory  a
> écrit :
> >>
> >>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >>> wrote:
> >>>
>  Le ven. 16 nov. 2018 21:23, Gary Gregory  a
> >>> écrit
>  :
> 
> > On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> >>>  >
> > wrote:
> >
> >> Oki, now the full VOTE text!
> >>
> >> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> >> The release was run with JDK-1.7 to ensure Java7 compatibility.
> >>
> >>
> >> The ASF staging repository is at
> >>
> >
> 
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >>
> >> The source zip is at
> >>
> >>
> >
> 
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> >> The sha1 of the source-release zip is
> >> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> >> The sha512 is
> >>
> >
> 
> >>>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >>
> >
> > For me:
> >
> > $ sha512sum commons-pool2-2.6.1-src.zip
> >
> >
> 
> >>>
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> > *commons-pool2-2.6.1-src.zip
> >
> > Which is not what you list above. Please advise.
> >
> 
>  Src vs source-release?
> 
> >>>
> >>> That's the problem with inventing a new release process... why do we
> have
> >>> BOTH:
> >>>
> >>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> >>> AND
> >>>
> >>>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
> >>>
> >>> And more importantly why are they _different_? Which one will be used
> in
> >>> the dist/release area?
> >>>
> >>
> >>
> >> Looks like pool didnt do its homework and kept the old assembly (src),
> >> source-release comes from the parent and is likely the one to keep IMHO
> >>
> >>
> >>> Gary
> >>>
> >>>
> >>>
> 
> 
> 
> 
> 
> > Gary
> >
> >
> >>
> >> I added my KEY (struberg at apache.org) to our dist KEYS file
> >> https://dist.apache.org/repos/dist/release/commons/KEYS
> >>
> >> I've created the release in a GIT manner and pushed the according
>  changes
> >> to my ASF-linked github repo
> >>
> >> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> >> the sha1 of the commit is
> >>
> >>
> >
> 
> >>>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >>
> >> the tag is
> >> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> >> c910171
> >> <
> >
> >>>
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> >
> >>
> >> This will get pushed to the ASF cannonical repo once the VOTE
> >>> succeeds.
> >>
> >> Site will be updated once the release has passed.
> >>
> >> Please VOTE:
> >>
> >> [+1] go ship it!
> >> [+0] meh, I don't care
> >> [-1] stop there is a ${showstopper} (t

[GitHub] commons-rng pull request #14: fix: removed 1.8 annotation to ensure 1.7 comp...

[aherbert]

GitHub user aherbert opened a pull request:

https://github.com/apache/commons-rng/pull/14

fix: removed 1.8 annotation to ensure 1.7 compliance

Noticed this JDK 1.8 annotation when compiling on a machine with Open JDK 
1.7 (it broke).

The pom.xml for commons-rng-examples uses 1.7 as the compliance level so 
this should be removed. The interface is not used with Lambda expressions 
anyway, i.e. the annotation should not be there.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/aherbert/commons-rng 
fix-jmh-java-version-1.7-compliance

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-rng/pull/14.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #14


commit 6dca4630fb4df34eb5e106dfbbe66bff271526ee
Author: aherbert 
Date:   2018-11-19T15:11:59Z

fix: removed 1.8 annotation to ensure 1.7 compliance




---

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

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Romain Manni-Bucau]

AFAIK source-release is quite standard @asf so likely saner to use that
from now on IMHO.
Agree sources is needed but Think Mark's point was more about assemblies
than default release artifacts.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 19 nov. 2018 à 15:54, Gary Gregory  a
écrit :

> On Mon, Nov 19, 2018 at 5:22 AM Mark Struberg 
> wrote:
>
> > Oki, I now see what you mean.
> >
> > We actually have 3 source zips now.
> >
> > .src.zip
> > .source-release.zip
> > src.jar
> >
> > That's a mess.
> >
> > There should only be 2:
> > * source-release.zip is the official ASF packages whole build sources.
> > This includes the pom, build structure etc.
> > * src.jar is the sources which are automatically downloaded by the IDEs
> > for debugging purpose.
> >
>
> Nope, it's the "-sources" jar that is used in IDEs. The "-src" jar is what
> _should_ contain all sources needed to build the jar and site.
>
> "source-release" is not something we've used here before IIRC.
>
> Gary
>
>
> >
> > We have both of them because commons-pool2 is a single-module project.
> > And yes, we need both of them. What we do not need is the src.zip. I have
> > no clue yet where this comes from but it shouldn't be here.
> >
> >
> > The good news:
> > By leveraging native GIT we now can simply a.) drop the maven stating
> repo
> > in repository.a.o and b.) drop the release branch and tag from my github
> > account and re-roll the release without any weird RC hacks.
> >
> > Will do that,
> > * fix the maven setup
> > * happy to also include the new ticket
> > * re-roll the release this afternoon.
> >
> > LieGrue,
> > strub
> >
> > > Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >
> > > Le ven. 16 nov. 2018 22:54, Gary Gregory  a
> > écrit :
> > >
> > >> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > >> wrote:
> > >>
> > >>> Le ven. 16 nov. 2018 21:23, Gary Gregory  a
> > >> écrit
> > >>> :
> > >>>
> >  On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> > >>  > 
> >  wrote:
> > 
> > > Oki, now the full VOTE text!
> > >
> > > I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> > > The release was run with JDK-1.7 to ensure Java7 compatibility.
> > >
> > >
> > > The ASF staging repository is at
> > >
> > 
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> > >
> > > The source zip is at
> > >
> > >
> > 
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > > The sha1 of the source-release zip is
> > > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > > The sha512 is
> > >
> > 
> > >>>
> > >>
> >
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> > >
> > 
> >  For me:
> > 
> >  $ sha512sum commons-pool2-2.6.1-src.zip
> > 
> > 
> > >>>
> > >>
> >
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> >  *commons-pool2-2.6.1-src.zip
> > 
> >  Which is not what you list above. Please advise.
> > 
> > >>>
> > >>> Src vs source-release?
> > >>>
> > >>
> > >> That's the problem with inventing a new release process... why do we
> > have
> > >> BOTH:
> > >>
> > >>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> > >> AND
> > >>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
> > >>
> > >> And more importantly why are they _different_? Which one will be used
> in
> > >> the dist/release area?
> > >>
> > >
> > >
> > > Looks like pool didnt do its homework and kept the old assembly (src),
> > > source-release comes from the parent and is likely the one to keep IMHO
> > >
> > >
> > >> Gary
> > >>
> > >>
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> >  Gary
> > 
> > 
> > >
> > > I added my KEY (struberg at apache.org) to our dist KEYS file
> > > https://dist.apache.org/repos/dist/release/commons/KEYS
> > >
> > > I've created the release in a GIT manner and pushed the according
> > >>> changes
> > > to my ASF-linked github repo
> > >
> > > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > > the sha1 of the commit is
> > >
> > >
> > 
> > >>>
> > >>
> >
> https://

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Gary Gregory]

On Mon, Nov 19, 2018 at 5:22 AM Mark Struberg 
wrote:

> Oki, I now see what you mean.
>
> We actually have 3 source zips now.
>
> .src.zip
> .source-release.zip
> src.jar
>
> That's a mess.
>
> There should only be 2:
> * source-release.zip is the official ASF packages whole build sources.
> This includes the pom, build structure etc.
> * src.jar is the sources which are automatically downloaded by the IDEs
> for debugging purpose.
>

Nope, it's the "-sources" jar that is used in IDEs. The "-src" jar is what
_should_ contain all sources needed to build the jar and site.

"source-release" is not something we've used here before IIRC.

Gary


>
> We have both of them because commons-pool2 is a single-module project.
> And yes, we need both of them. What we do not need is the src.zip. I have
> no clue yet where this comes from but it shouldn't be here.
>
>
> The good news:
> By leveraging native GIT we now can simply a.) drop the maven stating repo
> in repository.a.o and b.) drop the release branch and tag from my github
> account and re-roll the release without any weird RC hacks.
>
> Will do that,
> * fix the maven setup
> * happy to also include the new ticket
> * re-roll the release this afternoon.
>
> LieGrue,
> strub
>
> > Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau  >:
> >
> > Le ven. 16 nov. 2018 22:54, Gary Gregory  a
> écrit :
> >
> >> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> >> wrote:
> >>
> >>> Le ven. 16 nov. 2018 21:23, Gary Gregory  a
> >> écrit
> >>> :
> >>>
>  On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
> >>  
>  wrote:
> 
> > Oki, now the full VOTE text!
> >
> > I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> > The release was run with JDK-1.7 to ensure Java7 compatibility.
> >
> >
> > The ASF staging repository is at
> >
> 
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> >
> > The source zip is at
> >
> >
> 
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> > The sha1 of the source-release zip is
> > 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> > The sha512 is
> >
> 
> >>>
> >>
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> >
> 
>  For me:
> 
>  $ sha512sum commons-pool2-2.6.1-src.zip
> 
> 
> >>>
> >>
> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
>  *commons-pool2-2.6.1-src.zip
> 
>  Which is not what you list above. Please advise.
> 
> >>>
> >>> Src vs source-release?
> >>>
> >>
> >> That's the problem with inventing a new release process... why do we
> have
> >> BOTH:
> >>
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
> >> AND
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
> >>
> >> And more importantly why are they _different_? Which one will be used in
> >> the dist/release area?
> >>
> >
> >
> > Looks like pool didnt do its homework and kept the old assembly (src),
> > source-release comes from the parent and is likely the one to keep IMHO
> >
> >
> >> Gary
> >>
> >>
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
>  Gary
> 
> 
> >
> > I added my KEY (struberg at apache.org) to our dist KEYS file
> > https://dist.apache.org/repos/dist/release/commons/KEYS
> >
> > I've created the release in a GIT manner and pushed the according
> >>> changes
> > to my ASF-linked github repo
> >
> > https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> > the sha1 of the commit is
> >
> >
> 
> >>>
> >>
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> >
> > the tag is
> > https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> > c910171
> > <
> 
> >>
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> 
> >
> > This will get pushed to the ASF cannonical repo once the VOTE
> >> succeeds.
> >
> > Site will be updated once the release has passed.
> >
> > Please VOTE:
> >
> > [+1] go ship it!
> > [+0] meh, I don't care
> > [-1] stop there is a ${showstopper} (that means something _important_
> >>> is
> > missing!)
> >
> >
> > Here is my own +1
> > checked:
> > * signature
> > * hashes
> > * LICENSE
> > * NOTICE
> > * rat
> > * builds fine with various JDKs
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> >
> >> Am 14.11.2

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Rob Tompkins]

I’d be happy to roll the release if we get master to where you want it. 

Cheers,
-Rob

> On Nov 19, 2018, at 7:18 AM, Mark Struberg  wrote:
> 
> Oki, I now see what you mean.
> 
> We actually have 3 source zips now.
> 
> .src.zip
> .source-release.zip
> src.jar
> 
> That's a mess.
> 
> There should only be 2:
> * source-release.zip is the official ASF packages whole build sources. This 
> includes the pom, build structure etc.
> * src.jar is the sources which are automatically downloaded by the IDEs for 
> debugging purpose.
> 
> We have both of them because commons-pool2 is a single-module project.
> And yes, we need both of them. What we do not need is the src.zip. I have no 
> clue yet where this comes from but it shouldn't be here.
> 
> 
> The good news:
> By leveraging native GIT we now can simply a.) drop the maven stating repo in 
> repository.a.o and b.) drop the release branch and tag from my github account 
> and re-roll the release without any weird RC hacks.
> 
> Will do that, 
> * fix the maven setup
> * happy to also include the new ticket
> * re-roll the release this afternoon.
> 
> LieGrue,
> strub
> 
>> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau :
>> 
>> Le ven. 16 nov. 2018 22:54, Gary Gregory  a écrit :
>> 
>>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau 
>>> wrote:
>>> 
 Le ven. 16 nov. 2018 21:23, Gary Gregory  a
>>> écrit
 :
 
> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>>>  
> wrote:
> 
>> Oki, now the full VOTE text!
>> 
>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
>> The release was run with JDK-1.7 to ensure Java7 compatibility.
>> 
>> 
>> The ASF staging repository is at
>> 
> 
 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>> 
>> The source zip is at
>> 
>> 
> 
 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>> The sha1 of the source-release zip is
>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>> The sha512 is
>> 
> 
 
>>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>> 
> 
> For me:
> 
> $ sha512sum commons-pool2-2.6.1-src.zip
> 
> 
 
>>> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
> *commons-pool2-2.6.1-src.zip
> 
> Which is not what you list above. Please advise.
> 
 
 Src vs source-release?
 
>>> 
>>> That's the problem with inventing a new release process... why do we have
>>> BOTH:
>>> 
>>> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
>>> AND
>>> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>>> 
>>> And more importantly why are they _different_? Which one will be used in
>>> the dist/release area?
>>> 
>> 
>> 
>> Looks like pool didnt do its homework and kept the old assembly (src),
>> source-release comes from the parent and is likely the one to keep IMHO
>> 
>> 
>>> Gary
>>> 
>>> 
>>> 
 
 
 
 
 
> Gary
> 
> 
>> 
>> I added my KEY (struberg at apache.org) to our dist KEYS file
>> https://dist.apache.org/repos/dist/release/commons/KEYS
>> 
>> I've created the release in a GIT manner and pushed the according
 changes
>> to my ASF-linked github repo
>> 
>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>> the sha1 of the commit is
>> 
>> 
> 
 
>>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>> 
>> the tag is
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>> c910171
>> <
> 
>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
> 
>> 
>> This will get pushed to the ASF cannonical repo once the VOTE
>>> succeeds.
>> 
>> Site will be updated once the release has passed.
>> 
>> Please VOTE:
>> 
>> [+1] go ship it!
>> [+0] meh, I don't care
>> [-1] stop there is a ${showstopper} (that means something _important_
 is
>> missing!)
>> 
>> 
>> Here is my own +1
>> checked:
>> * signature
>> * hashes
>> * LICENSE
>> * NOTICE
>> * rat
>> * builds fine with various JDKs
>> 
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>> 
>> 
>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
 >> :
>>> 
>>> PS: I've created the release in a GIT manner and pushed the
>>> according
>> changes to my ASF-linked github repo
>>> 
>>> https://github.com/struber

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

Oki, I now see what you mean.

We actually have 3 source zips now.

.src.zip
.source-release.zip
src.jar

That's a mess.

There should only be 2:
* source-release.zip is the official ASF packages whole build sources. This 
includes the pom, build structure etc.
* src.jar is the sources which are automatically downloaded by the IDEs for 
debugging purpose.

We have both of them because commons-pool2 is a single-module project.
And yes, we need both of them. What we do not need is the src.zip. I have no 
clue yet where this comes from but it shouldn't be here.


The good news:
By leveraging native GIT we now can simply a.) drop the maven stating repo in 
repository.a.o and b.) drop the release branch and tag from my github account 
and re-roll the release without any weird RC hacks.

Will do that, 
* fix the maven setup
* happy to also include the new ticket
* re-roll the release this afternoon.

LieGrue,
strub

> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau :
> 
> Le ven. 16 nov. 2018 22:54, Gary Gregory  a écrit :
> 
>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau 
>> wrote:
>> 
>>> Le ven. 16 nov. 2018 21:23, Gary Gregory  a
>> écrit
>>> :
>>> 
 On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>> >>> 
 wrote:
 
> Oki, now the full VOTE text!
> 
> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> The release was run with JDK-1.7 to ensure Java7 compatibility.
> 
> 
> The ASF staging repository is at
> 
 
>>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> 
> The source zip is at
> 
> 
 
>>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> The sha1 of the source-release zip is
> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> The sha512 is
> 
 
>>> 
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> 
 
 For me:
 
 $ sha512sum commons-pool2-2.6.1-src.zip
 
 
>>> 
>> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
 *commons-pool2-2.6.1-src.zip
 
 Which is not what you list above. Please advise.
 
>>> 
>>> Src vs source-release?
>>> 
>> 
>> That's the problem with inventing a new release process... why do we have
>> BOTH:
>> 
>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
>> AND
>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>> 
>> And more importantly why are they _different_? Which one will be used in
>> the dist/release area?
>> 
> 
> 
> Looks like pool didnt do its homework and kept the old assembly (src),
> source-release comes from the parent and is likely the one to keep IMHO
> 
> 
>> Gary
>> 
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>>> 
 Gary
 
 
> 
> I added my KEY (struberg at apache.org) to our dist KEYS file
> https://dist.apache.org/repos/dist/release/commons/KEYS
> 
> I've created the release in a GIT manner and pushed the according
>>> changes
> to my ASF-linked github repo
> 
> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> the sha1 of the commit is
> 
> 
 
>>> 
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> 
> the tag is
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> c910171
> <
 
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
 
> 
> This will get pushed to the ASF cannonical repo once the VOTE
>> succeeds.
> 
> Site will be updated once the release has passed.
> 
> Please VOTE:
> 
> [+1] go ship it!
> [+0] meh, I don't care
> [-1] stop there is a ${showstopper} (that means something _important_
>>> is
> missing!)
> 
> 
> Here is my own +1
> checked:
> * signature
> * hashes
> * LICENSE
> * NOTICE
> * rat
> * builds fine with various JDKs
> 
> 
> LieGrue,
> strub
> 
> 
> 
> 
> 
>> Am 14.11.2018 um 10:13 schrieb Mark Struberg
>>> > :
>> 
>> PS: I've created the release in a GIT manner and pushed the
>> according
> changes to my ASF-linked github repo
>> 
>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>> the sha1 of the commit is
>> 
> 
 
>>> 
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>> 
>> the tag is
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>> c910171
>> 
>> This will get pushed to the ASF cannonical 

[GitHub] commons-rng issue #13: RNG-61: Remove unnecessary conditional from inside sh...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-rng/pull/13
  

[![Coverage 
Status](https://coveralls.io/builds/20175287/badge)](https://coveralls.io/builds/20175287)

Coverage increased (+0.009%) to 97.552% when pulling 
**d3ac7f75e2ed7e21fc48c5db8c5ea8bfbe3533f3 on aherbert:improvement-RNG-61** 
into **0fdcd9007c708aa48f1989cb2211ea56c1fcd702 on apache:master**.



---

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

[GitHub] commons-rng pull request #13: RNG-61: Remove unnecessary conditional from in...

[aherbert]

GitHub user aherbert opened a pull request:

https://github.com/apache/commons-rng/pull/13

RNG-61: Remove unnecessary conditional from inside shuffle loop

I have also updated the constructor exception messages to be clearer on 
what has failed and added a Javadoc link to a definition of Permutation.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/aherbert/commons-rng improvement-RNG-61

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-rng/pull/13.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #13


commit d3ac7f75e2ed7e21fc48c5db8c5ea8bfbe3533f3
Author: Alex Herbert 
Date:   2018-11-19T08:54:17Z

RNG-61: Remove unnecessary conditional from inside shuffle loop




---

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