Re: [COLLECTIONS] Test failures on Windows

[Bruno P. Kinoshita]

It was merged in 
https://github.com/apache/commons-collections/commit/eed8a7adb3de7441751e846f4a75d110dd205f23.
I closed the pull request.
Thanks to all that helped testing & troubleshooting this interesting issue!
I believe Commons Collections should now be in a state ready for a release.
CheersBruno
  From: Benedikt Ritter 
 To: Commons Developers List  
 Sent: Thursday, 12 October 2017 7:23 PM
 Subject: Re: [COLLECTIONS] Test failures on Windows
   
Awesome, let’s merge this!

> Am 11.10.2017 um 13:06 schrieb Andreas Kuhtz :
> 
> Hi,
> 
> Tested with the changes of your PR multiple times with Win7-64bit and JDK7
> and JDK8 without any issues.
> 
> Cheers
> Andreas
> 
> 
> 
> 2017-10-11 10:03 GMT+02:00 Bruno P. Kinoshita <
> brunodepau...@yahoo.com.br.invalid>:
> 
>> Done.
>> https://github.com/apache/commons-collections/pull/28
>> 
>> Tested on Windows 10 + JDK8, and Ubuntu LTS + JDK8.
>> Would be good if someone else with a Windows version could try it too, and
>> if others could have a look at the suggested solution in the pull request
>> to see if there's a better way of doing it.
>> CheersBruno
>>      From: Bruno P. Kinoshita 
>> To: Commons Developers List 
>> Sent: Wednesday, 11 October 2017 12:43 PM
>> Subject: Re: [COLLECTIONS] Test failures on Windows
>> 
>> Still investigating. Trying to isolate the problem
>> https://github.com/kinow/commons-collections/tree/COLLECTIONS-661-1
>> 
>> No luck so far. I have an environment where it happens over 90% of the
>> time. Tried debugging a few times, adding some sysout statements to see if
>> there was anything suspect... yesterday enabled findbugs in test to look
>> for any issue in the test classes. Nothing yet.
>> 
>> Bruno
>> 
>>      From: Gary Gregory 
>> To: Commons Developers List 
>> Sent: Wednesday, 11 October 2017 12:13 PM
>> Subject: Re: [COLLECTIONS] Test failures on Windows
>> 
>> Where are we on this one?
>> 
>> Gary
>> 
>> On Mon, Oct 2, 2017 at 3:34 AM, Pascal Schumacher <
>> pascalschumac...@gmx.net>
>> wrote:
>> 
>>> Looks like the random failures are not limited to window. The travis
>> build
>>> (ubuntu), just failed with 44 failures, e.g.
>>> 
>>> AbstractMultiValuedMapTest$TestMultiValuedMapAsMap>AbstractM
>>> apTest.testMapToString:745->AbstractMapTest.verify:1947->
>> AbstractMapTest.verifyMap:1958
>>> hashCodes should be the same expected:<205172737> but was:<9372706>
>>> 
>>> 
>>> see: https://travis-ci.org/apache/commons-collections/jobs/282169803
>>> 
>>> 
>>> Am 28.09.2017 um 20:23 schrieb Andreas Kuhtz:
>>> 
 Hi,
 
 2017-09-27 22:28 GMT+02:00 Bruno P. Kinoshita :
 
 Forgot to mention something important. When I was debugging the hash
> tests, they would pretty much always pass.
> 
> But if I ran the tests normally in maven or eclipse they would always
> fail.
> 
> Debugging adds a small overhead I think, that could be slowing down
>> some
> part of the code with a concurrency issue?
> 
> That's an explanation. If I start a Virtualbox instance that prepares
 some
 load I can see the tests pass under Java 9 ... I had the Virtualbox
 running
 yesterday when the tests passed.
 
 
 Just in case it helps...
> 
> Interesting this surefire configuration Andreas. Do you have more
> information about it? Is it something we may have to worry about in
> components that use locale and jvm 9?
> 
> I ran into an issue with the language selection dialog of izpack and
 found
 that this configuration solved the problem there.
 It's noted in the release notes of Java 9:
 http://www.oracle.com/technetwork/java/javase/9-relnote-
 issues-3704069.html#JDK-8008577
 
 Cheers,
 Andreas
 
 
 Cheers
> Bruno
> 
> Sent from Yahoo Mail on Android
> 
> 
> On Thu, 28 Sep 2017 at 4:45, Andreas Kuhtz
>  wrote:
> Hi,
> 
> I'm running Win7 and with "mvn clean verify". Checkout master.
> 
> I got the hash code errors, too. But sometimes the tests pass, the next
> time they failed with 44 failures (the hash code verification).
> 
> As I'm not sure if my antivirus kicks in and keep some files in the
> target
> dir, I ran "mvn clean" and after that "mvn clean verify".
> But now I have the 44 failures with jdk-1.7.0_67, jdk-1.8.0_131 and
>> 9+181
> 
> Gary:
> To get around the issue with ServiceConfiguration sun.util.locale...  I
> added the following profile to the pom.xml. After that I only got the
>> 44
> errors (hash code) as with Java 7 and 8.
> 
>    
>      jdk9-build
>      
>        9
>      
>      
>        
>          
>            maven-surefire-plugin
>            
>              -Djava.locale.providers=COMPAT
>            
>          
>        
>      
>    
> 
> I'm not sure 

[GitHub] commons-collections pull request #28: COLLECTIONS-661: fix for concurrency i...

[kinow]

Github user kinow closed the pull request at:

https://github.com/apache/commons-collections/pull/28


---

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

[GitHub] commons-collections issue #28: COLLECTIONS-661: fix for concurrency issue in...

[kinow]

Github user kinow commented on the issue:

https://github.com/apache/commons-collections/pull/28
  
Merged 
inhttps://github.com/apache/commons-collections/commit/eed8a7adb3de7441751e846f4a75d110dd205f23.
 Closing it.


---

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

[GitHub] commons-collections pull request #28: COLLECTIONS-661: fix for concurrency i...

[kinow]

Github user kinow closed the pull request at:

https://github.com/apache/commons-collections/pull/28


---

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

Re: [COLLECTIONS] Test failures on Windows

[Benedikt Ritter]

Awesome, let’s merge this!

> Am 11.10.2017 um 13:06 schrieb Andreas Kuhtz :
> 
> Hi,
> 
> Tested with the changes of your PR multiple times with Win7-64bit and JDK7
> and JDK8 without any issues.
> 
> Cheers
> Andreas
> 
> 
> 
> 2017-10-11 10:03 GMT+02:00 Bruno P. Kinoshita <
> brunodepau...@yahoo.com.br.invalid>:
> 
>> Done.
>> https://github.com/apache/commons-collections/pull/28
>> 
>> Tested on Windows 10 + JDK8, and Ubuntu LTS + JDK8.
>> Would be good if someone else with a Windows version could try it too, and
>> if others could have a look at the suggested solution in the pull request
>> to see if there's a better way of doing it.
>> CheersBruno
>>  From: Bruno P. Kinoshita 
>> To: Commons Developers List 
>> Sent: Wednesday, 11 October 2017 12:43 PM
>> Subject: Re: [COLLECTIONS] Test failures on Windows
>> 
>> Still investigating. Trying to isolate the problem
>> https://github.com/kinow/commons-collections/tree/COLLECTIONS-661-1
>> 
>> No luck so far. I have an environment where it happens over 90% of the
>> time. Tried debugging a few times, adding some sysout statements to see if
>> there was anything suspect... yesterday enabled findbugs in test to look
>> for any issue in the test classes. Nothing yet.
>> 
>> Bruno
>> 
>>  From: Gary Gregory 
>> To: Commons Developers List 
>> Sent: Wednesday, 11 October 2017 12:13 PM
>> Subject: Re: [COLLECTIONS] Test failures on Windows
>> 
>> Where are we on this one?
>> 
>> Gary
>> 
>> On Mon, Oct 2, 2017 at 3:34 AM, Pascal Schumacher <
>> pascalschumac...@gmx.net>
>> wrote:
>> 
>>> Looks like the random failures are not limited to window. The travis
>> build
>>> (ubuntu), just failed with 44 failures, e.g.
>>> 
>>> AbstractMultiValuedMapTest$TestMultiValuedMapAsMap>AbstractM
>>> apTest.testMapToString:745->AbstractMapTest.verify:1947->
>> AbstractMapTest.verifyMap:1958
>>> hashCodes should be the same expected:<205172737> but was:<9372706>
>>> 
>>> 
>>> see: https://travis-ci.org/apache/commons-collections/jobs/282169803
>>> 
>>> 
>>> Am 28.09.2017 um 20:23 schrieb Andreas Kuhtz:
>>> 
 Hi,
 
 2017-09-27 22:28 GMT+02:00 Bruno P. Kinoshita :
 
 Forgot to mention something important. When I was debugging the hash
> tests, they would pretty much always pass.
> 
> But if I ran the tests normally in maven or eclipse they would always
> fail.
> 
> Debugging adds a small overhead I think, that could be slowing down
>> some
> part of the code with a concurrency issue?
> 
> That's an explanation. If I start a Virtualbox instance that prepares
 some
 load I can see the tests pass under Java 9 ... I had the Virtualbox
 running
 yesterday when the tests passed.
 
 
 Just in case it helps...
> 
> Interesting this surefire configuration Andreas. Do you have more
> information about it? Is it something we may have to worry about in
> components that use locale and jvm 9?
> 
> I ran into an issue with the language selection dialog of izpack and
 found
 that this configuration solved the problem there.
 It's noted in the release notes of Java 9:
 http://www.oracle.com/technetwork/java/javase/9-relnote-
 issues-3704069.html#JDK-8008577
 
 Cheers,
 Andreas
 
 
 Cheers
> Bruno
> 
> Sent from Yahoo Mail on Android
> 
> 
> On Thu, 28 Sep 2017 at 4:45, Andreas Kuhtz
>  wrote:
> Hi,
> 
> I'm running Win7 and with "mvn clean verify". Checkout master.
> 
> I got the hash code errors, too. But sometimes the tests pass, the next
> time they failed with 44 failures (the hash code verification).
> 
> As I'm not sure if my antivirus kicks in and keep some files in the
> target
> dir, I ran "mvn clean" and after that "mvn clean verify".
> But now I have the 44 failures with jdk-1.7.0_67, jdk-1.8.0_131 and
>> 9+181
> 
> Gary:
> To get around the issue with ServiceConfiguration sun.util.locale...  I
> added the following profile to the pom.xml. After that I only got the
>> 44
> errors (hash code) as with Java 7 and 8.
> 
> 
>   jdk9-build
>   
> 9
>   
>   
> 
>   
> maven-surefire-plugin
> 
>   -Djava.locale.providers=COMPAT
> 
>   
> 
>   
> 
> 
> I'm not sure if I can help more, but if you need more info just let me
> know.
> 
> Andreas
> 
> 2017-09-27 19:10 GMT+02:00 Gary Gregory :
> 
> Using git master and 'mvn clean verify', on Windows 10, with Java 7, I
>> 
> get
> 
>> 44 failures, and I think this is all/mostly hash code problems.
>> 
>> With Java 8, all tests pass.
>> 
>> With Java 9, I get ONE failure: ListIteratorWrapperTest.
>> t

[GitHub] commons-collections issue #27: travis: add java 9 to build

[vamsi-kavuri]

Github user vamsi-kavuri commented on the issue:

https://github.com/apache/commons-collections/pull/27
  
#30 would resolve build issues in java9


---

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

[GitHub] commons-collections issue #30: COLLECTIONS-662 : Override Jacoco version for...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-collections/pull/30
  

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

Coverage remained the same at 86.616% when pulling 
**627b825a24eb03fb5d29f2eb5243034bafc12d94 on vamsi-kavuri:java9_compat** into 
**07de4dd578727555bb94ed421498f455838b317d on apache:master**.



---

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

[GitHub] commons-collections pull request #30: COLLECTIONS-662 : Override Jacoco vers...

[vamsi-kavuri]

GitHub user vamsi-kavuri opened a pull request:

https://github.com/apache/commons-collections/pull/30

 COLLECTIONS-662 : Override Jacoco version for Java9 compatibility

Overriding Jacoco version fixed the failures in Java 9.

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

$ git pull https://github.com/vamsi-kavuri/commons-collections java9_compat

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

https://github.com/apache/commons-collections/pull/30.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 #30


commit 191826a52a3d77a821d3715cc4074ed6348b6e0a
Author: Kavuri, Vamsi 
Date:   2017-10-12T04:04:10Z

override jacoco version for java9 compatibiltiy

commit 627b825a24eb03fb5d29f2eb5243034bafc12d94
Author: Vamsi 
Date:   2017-10-12T04:05:46Z

Update pom.xml




---

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

Re: [COLLECTIONS] Test failures on Windows

[Gary Gregory]

Works like a charm for me on Windows 10 and

Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T13:39:06-06:00)
Maven home: C:\Java\apache-maven-3.5.0\bin\..
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_144\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Committed!
:-)
Gary

On Wed, Oct 11, 2017 at 5:06 AM, Andreas Kuhtz 
wrote:

> Hi,
>
> Tested with the changes of your PR multiple times with Win7-64bit and JDK7
> and JDK8 without any issues.
>
> Cheers
> Andreas
>
>
>
> 2017-10-11 10:03 GMT+02:00 Bruno P. Kinoshita <
> brunodepau...@yahoo.com.br.invalid>:
>
> > Done.
> > https://github.com/apache/commons-collections/pull/28
> >
> > Tested on Windows 10 + JDK8, and Ubuntu LTS + JDK8.
> > Would be good if someone else with a Windows version could try it too,
> and
> > if others could have a look at the suggested solution in the pull request
> > to see if there's a better way of doing it.
> > CheersBruno
> >   From: Bruno P. Kinoshita 
> >  To: Commons Developers List 
> >  Sent: Wednesday, 11 October 2017 12:43 PM
> >  Subject: Re: [COLLECTIONS] Test failures on Windows
> >
> > Still investigating. Trying to isolate the problem
> > https://github.com/kinow/commons-collections/tree/COLLECTIONS-661-1
> >
> > No luck so far. I have an environment where it happens over 90% of the
> > time. Tried debugging a few times, adding some sysout statements to see
> if
> > there was anything suspect... yesterday enabled findbugs in test to look
> > for any issue in the test classes. Nothing yet.
> >
> > Bruno
> >
> >   From: Gary Gregory 
> >  To: Commons Developers List 
> >  Sent: Wednesday, 11 October 2017 12:13 PM
> >  Subject: Re: [COLLECTIONS] Test failures on Windows
> >
> > Where are we on this one?
> >
> > Gary
> >
> > On Mon, Oct 2, 2017 at 3:34 AM, Pascal Schumacher <
> > pascalschumac...@gmx.net>
> > wrote:
> >
> > > Looks like the random failures are not limited to window. The travis
> > build
> > > (ubuntu), just failed with 44 failures, e.g.
> > >
> > > AbstractMultiValuedMapTest$TestMultiValuedMapAsMap>AbstractM
> > > apTest.testMapToString:745->AbstractMapTest.verify:1947->
> > AbstractMapTest.verifyMap:1958
> > > hashCodes should be the same expected:<205172737> but was:<9372706>
> > >
> > >
> > > see: https://travis-ci.org/apache/commons-collections/jobs/282169803
> > >
> > >
> > > Am 28.09.2017 um 20:23 schrieb Andreas Kuhtz:
> > >
> > >> Hi,
> > >>
> > >> 2017-09-27 22:28 GMT+02:00 Bruno P. Kinoshita :
> > >>
> > >> Forgot to mention something important. When I was debugging the hash
> > >>> tests, they would pretty much always pass.
> > >>>
> > >>> But if I ran the tests normally in maven or eclipse they would always
> > >>> fail.
> > >>>
> > >>> Debugging adds a small overhead I think, that could be slowing down
> > some
> > >>> part of the code with a concurrency issue?
> > >>>
> > >>> That's an explanation. If I start a Virtualbox instance that prepares
> > >> some
> > >> load I can see the tests pass under Java 9 ... I had the Virtualbox
> > >> running
> > >> yesterday when the tests passed.
> > >>
> > >>
> > >> Just in case it helps...
> > >>>
> > >>> Interesting this surefire configuration Andreas. Do you have more
> > >>> information about it? Is it something we may have to worry about in
> > >>> components that use locale and jvm 9?
> > >>>
> > >>> I ran into an issue with the language selection dialog of izpack and
> > >> found
> > >> that this configuration solved the problem there.
> > >> It's noted in the release notes of Java 9:
> > >> http://www.oracle.com/technetwork/java/javase/9-relnote-
> > >> issues-3704069.html#JDK-8008577
> > >>
> > >> Cheers,
> > >> Andreas
> > >>
> > >>
> > >> Cheers
> > >>> Bruno
> > >>>
> > >>> Sent from Yahoo Mail on Android
> > >>> 
> > >>>
> > >>> On Thu, 28 Sep 2017 at 4:45, Andreas Kuhtz
> > >>>  wrote:
> > >>> Hi,
> > >>>
> > >>> I'm running Win7 and with "mvn clean verify". Checkout master.
> > >>>
> > >>> I got the hash code errors, too. But sometimes the tests pass, the
> next
> > >>> time they failed with 44 failures (the hash code verification).
> > >>>
> > >>> As I'm not sure if my antivirus kicks in and keep some files in the
> > >>> target
> > >>> dir, I ran "mvn clean" and after that "mvn clean verify".
> > >>> But now I have the 44 failures with jdk-1.7.0_67, jdk-1.8.0_131 and
> > 9+181
> > >>>
> > >>> Gary:
> > >>> To get around the issue with ServiceConfiguration
> sun.util.locale...  I
> > >>> added the following profile to the pom.xml. After that I only got the
> > 44
> > >>> errors (hash code) as with Java 7 and 8.
> > >>>
> > >>>  
> > >>>jdk9-build
> > >>>
> > >>>  9
> > >>>
> > >>>
> > >>>  
> > >>>
> > >>>  maven-surefire-plugin
> > >>>  

[GitHub] commons-collections issue #29: Added unit tests to increase code coverage

[PascalSchumacher]

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-collections/pull/29
  
Thanks!


---

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

[GitHub] commons-collections pull request #29: Added unit tests to increase code cove...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-collections/pull/29


---

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

[GitHub] commons-collections pull request #29: Added unit tests to increase code cove...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-collections/pull/29


---

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

[GitHub] commons-collections issue #29: Added unit tests to increase code coverage

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-collections/pull/29
  

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

Coverage increased (+1.5%) to 86.616% when pulling 
**d6e4c2e98b525b4553ef0baab76246c2b9a0ae70 on vamsi-kavuri:Unit_tests** into 
**1d21a49c27d9eab8d02785a783fcfba387a3e8e1 on apache:master**.



---

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

[GitHub] commons-collections pull request #29: Added unit tests to increase coverage

[vamsi-kavuri]

GitHub user vamsi-kavuri opened a pull request:

https://github.com/apache/commons-collections/pull/29

Added unit tests to increase coverage



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

$ git pull https://github.com/vamsi-kavuri/commons-collections Unit_tests

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

https://github.com/apache/commons-collections/pull/29.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 #29


commit bcaa1484b830a45b5ae8f975ba8816a48cc462ed
Author: Kavuri, Vamsi 
Date:   2017-06-12T16:37:26Z

COLLECTIONS-606:Added build and coverage status

commit 676c353e0c24450ac4fc1435db1b8e0df3384e3b
Author: Vamsi 
Date:   2017-06-12T16:43:03Z

Merge pull request #1 from vamsi-kavuri/COLLECTIONS-606-BuildStatus

COLLECTIONS-606:Added build and coverage status

commit cc079f8c834d505b8485da1ebd935ee269600628
Author: Kavuri, Vamsi 
Date:   2017-10-10T02:40:55Z

Merge branch 'master' of https://github.com/apache/commons-collections into 
COLLECTIONS-606-BuildStatus

commit d6e4c2e98b525b4553ef0baab76246c2b9a0ae70
Author: Kavuri, Vamsi 
Date:   2017-10-11T21:46:05Z

Add unit test cases




---

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

Re: [RESULT][VOTE] Release Commons Configuration 2.2 based on RC1

[Gary Gregory]

Can you release from Nexus ASAP SVP?

Gary

On Oct 11, 2017 14:24, "Oliver Heger"  wrote:

> The vote to release Commons Configuration 2.2 based on RC1 passed with
> the following binding votes:
>
> Bruno P. Kinoshita: +1
> Gary Gregory:   +1
> Rob Tompkins:   +1
> Oliver Heger:   +1
>
> No other votes were cast.
>
> Thanks to all who took the time to review the RC. I will start the
> release procedure in the next days.
>
> Oliver
>
> Am 08.10.2017 um 22:24 schrieb Oliver Heger:
> > Hi all,
> >
> > there was a request for a new release on the ML, so here we go.
> >
> > Configuration 2.2 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/configuration/ (rev.
> 22170)
> >
> > The tag is here:
> >
> > http://svn.apache.org/repos/asf/commons/proper/configuration/tags/
> CONFIGURATION_2_2_RC1/
> > (rev. 1811500)
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/
> orgapachecommons-1273/org/apache/commons/commons-configuration2/2.2/
> >
> > Details of changes since 1.1 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/
> configuration/RELEASE-NOTES.txt
> > http://home.apache.org/~oheger/configuration-2.2-rc1/
> changes-report.html
> >
> > Site:
> > http://home.apache.org/~oheger/configuration-2.2-rc1/
> >   (note some *relative* links are broken and the 1.2 directories are
> >   not yet created - these will be OK once the site is deployed)
> >
> > Clirr Report (compared to 2.1.1):
> > http://home.apache.org/~oheger/configuration-2.2-rc1/
> clirr-report.html
> >
> > RAT Report:
> > http://home.apache.org/~oheger/configuration-2.2-rc1/rat-report.html
> >
> > KEYS:
> >   https://www.apache.org/dist/commons/KEYS
> >
> > Please review the release candidate and vote.
> > This vote will close no sooner that 72 hours from now,
> > i.e. sometime after 22:00 UTC 11-October 2017
> >
> >   [ ] +1 Release these artifacts
> >   [ ] +0 OK, but...
> >   [ ] -0 OK, but really should fix...
> >   [ ] -1 I oppose this release because...
> >
> > Thanks!
> > Oliver
> >
> >
> > -
> > 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 Commons Configuration 2.2 based on RC1

[Oliver Heger]

The vote to release Commons Configuration 2.2 based on RC1 passed with
the following binding votes:

Bruno P. Kinoshita: +1
Gary Gregory:   +1
Rob Tompkins:   +1
Oliver Heger:   +1

No other votes were cast.

Thanks to all who took the time to review the RC. I will start the
release procedure in the next days.

Oliver

Am 08.10.2017 um 22:24 schrieb Oliver Heger:
> Hi all,
> 
> there was a request for a new release on the ML, so here we go.
> 
> Configuration 2.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/configuration/ (rev. 22170)
> 
> The tag is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_2_RC1/
> (rev. 1811500)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1273/org/apache/commons/commons-configuration2/2.2/
> 
> Details of changes since 1.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt
> http://home.apache.org/~oheger/configuration-2.2-rc1/changes-report.html
> 
> Site:
> http://home.apache.org/~oheger/configuration-2.2-rc1/
>   (note some *relative* links are broken and the 1.2 directories are
>   not yet created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 2.1.1):
> http://home.apache.org/~oheger/configuration-2.2-rc1/clirr-report.html
> 
> RAT Report:
> http://home.apache.org/~oheger/configuration-2.2-rc1/rat-report.html
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 22:00 UTC 11-October 2017
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks!
> Oliver
> 
> 
> -
> 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 Commons Configuration 2.2 based on RC1

[Oliver Heger]

My own +1

Oliver

Am 08.10.2017 um 22:24 schrieb Oliver Heger:
> Hi all,
> 
> there was a request for a new release on the ML, so here we go.
> 
> Configuration 2.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/configuration/ (rev. 22170)
> 
> The tag is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_2_RC1/
> (rev. 1811500)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1273/org/apache/commons/commons-configuration2/2.2/
> 
> Details of changes since 1.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt
> http://home.apache.org/~oheger/configuration-2.2-rc1/changes-report.html
> 
> Site:
> http://home.apache.org/~oheger/configuration-2.2-rc1/
>   (note some *relative* links are broken and the 1.2 directories are
>   not yet created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 2.1.1):
> http://home.apache.org/~oheger/configuration-2.2-rc1/clirr-report.html
> 
> RAT Report:
> http://home.apache.org/~oheger/configuration-2.2-rc1/rat-report.html
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 22:00 UTC 11-October 2017
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks!
> Oliver
> 
> 
> -
> 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

[GitHub] commons-text issue #68: TEXT-74 Introduced new StrSubstitutor attribute to d...

[arend-von-reinersdorff]

Github user arend-von-reinersdorff commented on the issue:

https://github.com/apache/commons-text/pull/68
  
@sermojohn Great, thanks :-)


---

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

Re: [COLLECTIONS] Test failures on Windows

[Andreas Kuhtz]

Hi,

Tested with the changes of your PR multiple times with Win7-64bit and JDK7
and JDK8 without any issues.

Cheers
Andreas



2017-10-11 10:03 GMT+02:00 Bruno P. Kinoshita <
brunodepau...@yahoo.com.br.invalid>:

> Done.
> https://github.com/apache/commons-collections/pull/28
>
> Tested on Windows 10 + JDK8, and Ubuntu LTS + JDK8.
> Would be good if someone else with a Windows version could try it too, and
> if others could have a look at the suggested solution in the pull request
> to see if there's a better way of doing it.
> CheersBruno
>   From: Bruno P. Kinoshita 
>  To: Commons Developers List 
>  Sent: Wednesday, 11 October 2017 12:43 PM
>  Subject: Re: [COLLECTIONS] Test failures on Windows
>
> Still investigating. Trying to isolate the problem
> https://github.com/kinow/commons-collections/tree/COLLECTIONS-661-1
>
> No luck so far. I have an environment where it happens over 90% of the
> time. Tried debugging a few times, adding some sysout statements to see if
> there was anything suspect... yesterday enabled findbugs in test to look
> for any issue in the test classes. Nothing yet.
>
> Bruno
>
>   From: Gary Gregory 
>  To: Commons Developers List 
>  Sent: Wednesday, 11 October 2017 12:13 PM
>  Subject: Re: [COLLECTIONS] Test failures on Windows
>
> Where are we on this one?
>
> Gary
>
> On Mon, Oct 2, 2017 at 3:34 AM, Pascal Schumacher <
> pascalschumac...@gmx.net>
> wrote:
>
> > Looks like the random failures are not limited to window. The travis
> build
> > (ubuntu), just failed with 44 failures, e.g.
> >
> > AbstractMultiValuedMapTest$TestMultiValuedMapAsMap>AbstractM
> > apTest.testMapToString:745->AbstractMapTest.verify:1947->
> AbstractMapTest.verifyMap:1958
> > hashCodes should be the same expected:<205172737> but was:<9372706>
> >
> >
> > see: https://travis-ci.org/apache/commons-collections/jobs/282169803
> >
> >
> > Am 28.09.2017 um 20:23 schrieb Andreas Kuhtz:
> >
> >> Hi,
> >>
> >> 2017-09-27 22:28 GMT+02:00 Bruno P. Kinoshita :
> >>
> >> Forgot to mention something important. When I was debugging the hash
> >>> tests, they would pretty much always pass.
> >>>
> >>> But if I ran the tests normally in maven or eclipse they would always
> >>> fail.
> >>>
> >>> Debugging adds a small overhead I think, that could be slowing down
> some
> >>> part of the code with a concurrency issue?
> >>>
> >>> That's an explanation. If I start a Virtualbox instance that prepares
> >> some
> >> load I can see the tests pass under Java 9 ... I had the Virtualbox
> >> running
> >> yesterday when the tests passed.
> >>
> >>
> >> Just in case it helps...
> >>>
> >>> Interesting this surefire configuration Andreas. Do you have more
> >>> information about it? Is it something we may have to worry about in
> >>> components that use locale and jvm 9?
> >>>
> >>> I ran into an issue with the language selection dialog of izpack and
> >> found
> >> that this configuration solved the problem there.
> >> It's noted in the release notes of Java 9:
> >> http://www.oracle.com/technetwork/java/javase/9-relnote-
> >> issues-3704069.html#JDK-8008577
> >>
> >> Cheers,
> >> Andreas
> >>
> >>
> >> Cheers
> >>> Bruno
> >>>
> >>> Sent from Yahoo Mail on Android
> >>> 
> >>>
> >>> On Thu, 28 Sep 2017 at 4:45, Andreas Kuhtz
> >>>  wrote:
> >>> Hi,
> >>>
> >>> I'm running Win7 and with "mvn clean verify". Checkout master.
> >>>
> >>> I got the hash code errors, too. But sometimes the tests pass, the next
> >>> time they failed with 44 failures (the hash code verification).
> >>>
> >>> As I'm not sure if my antivirus kicks in and keep some files in the
> >>> target
> >>> dir, I ran "mvn clean" and after that "mvn clean verify".
> >>> But now I have the 44 failures with jdk-1.7.0_67, jdk-1.8.0_131 and
> 9+181
> >>>
> >>> Gary:
> >>> To get around the issue with ServiceConfiguration sun.util.locale...  I
> >>> added the following profile to the pom.xml. After that I only got the
> 44
> >>> errors (hash code) as with Java 7 and 8.
> >>>
> >>>  
> >>>jdk9-build
> >>>
> >>>  9
> >>>
> >>>
> >>>  
> >>>
> >>>  maven-surefire-plugin
> >>>  
> >>>-Djava.locale.providers=COMPAT
> >>>  
> >>>
> >>>  
> >>>
> >>>  
> >>>
> >>> I'm not sure if I can help more, but if you need more info just let me
> >>> know.
> >>>
> >>> Andreas
> >>>
> >>> 2017-09-27 19:10 GMT+02:00 Gary Gregory :
> >>>
> >>> Using git master and 'mvn clean verify', on Windows 10, with Java 7, I
> 
> >>> get
> >>>
>  44 failures, and I think this is all/mostly hash code problems.
> 
>  With Java 8, all tests pass.
> 
>  With Java 9, I get ONE failure: ListIteratorWrapperTest.
> testRemove:116
>  ╗
>  ServiceConfiguration sun.util.locale
> 
>  If I checkout the 4.1 tag and use Java 7, I get 44 failures. ARG! What
> 
> >

[GitHub] commons-rng pull request #5: Feature rng 37

[asfgit]

Github user asfgit closed the pull request at:

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


---

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

Re: [COLLECTIONS] Test failures on Windows

[Bruno P. Kinoshita]

Done.
https://github.com/apache/commons-collections/pull/28

Tested on Windows 10 + JDK8, and Ubuntu LTS + JDK8.
Would be good if someone else with a Windows version could try it too, and if 
others could have a look at the suggested solution in the pull request to see 
if there's a better way of doing it.
CheersBruno
  From: Bruno P. Kinoshita 
 To: Commons Developers List  
 Sent: Wednesday, 11 October 2017 12:43 PM
 Subject: Re: [COLLECTIONS] Test failures on Windows
   
Still investigating. Trying to isolate the problem 
https://github.com/kinow/commons-collections/tree/COLLECTIONS-661-1

No luck so far. I have an environment where it happens over 90% of the time. 
Tried debugging a few times, adding some sysout statements to see if there was 
anything suspect... yesterday enabled findbugs in test to look for any issue in 
the test classes. Nothing yet.

Bruno

      From: Gary Gregory 
 To: Commons Developers List  
 Sent: Wednesday, 11 October 2017 12:13 PM
 Subject: Re: [COLLECTIONS] Test failures on Windows
  
Where are we on this one?

Gary

On Mon, Oct 2, 2017 at 3:34 AM, Pascal Schumacher 
wrote:

> Looks like the random failures are not limited to window. The travis build
> (ubuntu), just failed with 44 failures, e.g.
>
> AbstractMultiValuedMapTest$TestMultiValuedMapAsMap>AbstractM
> apTest.testMapToString:745->AbstractMapTest.verify:1947->AbstractMapTest.verifyMap:1958
> hashCodes should be the same expected:<205172737> but was:<9372706>
>
>
> see: https://travis-ci.org/apache/commons-collections/jobs/282169803
>
>
> Am 28.09.2017 um 20:23 schrieb Andreas Kuhtz:
>
>> Hi,
>>
>> 2017-09-27 22:28 GMT+02:00 Bruno P. Kinoshita :
>>
>> Forgot to mention something important. When I was debugging the hash
>>> tests, they would pretty much always pass.
>>>
>>> But if I ran the tests normally in maven or eclipse they would always
>>> fail.
>>>
>>> Debugging adds a small overhead I think, that could be slowing down some
>>> part of the code with a concurrency issue?
>>>
>>> That's an explanation. If I start a Virtualbox instance that prepares
>> some
>> load I can see the tests pass under Java 9 ... I had the Virtualbox
>> running
>> yesterday when the tests passed.
>>
>>
>> Just in case it helps...
>>>
>>> Interesting this surefire configuration Andreas. Do you have more
>>> information about it? Is it something we may have to worry about in
>>> components that use locale and jvm 9?
>>>
>>> I ran into an issue with the language selection dialog of izpack and
>> found
>> that this configuration solved the problem there.
>> It's noted in the release notes of Java 9:
>> http://www.oracle.com/technetwork/java/javase/9-relnote-
>> issues-3704069.html#JDK-8008577
>>
>> Cheers,
>> Andreas
>>
>>
>> Cheers
>>> Bruno
>>>
>>> Sent from Yahoo Mail on Android
>>> 
>>>
>>> On Thu, 28 Sep 2017 at 4:45, Andreas Kuhtz
>>>  wrote:
>>> Hi,
>>>
>>> I'm running Win7 and with "mvn clean verify". Checkout master.
>>>
>>> I got the hash code errors, too. But sometimes the tests pass, the next
>>> time they failed with 44 failures (the hash code verification).
>>>
>>> As I'm not sure if my antivirus kicks in and keep some files in the
>>> target
>>> dir, I ran "mvn clean" and after that "mvn clean verify".
>>> But now I have the 44 failures with jdk-1.7.0_67, jdk-1.8.0_131 and 9+181
>>>
>>> Gary:
>>> To get around the issue with ServiceConfiguration sun.util.locale...  I
>>> added the following profile to the pom.xml. After that I only got the 44
>>> errors (hash code) as with Java 7 and 8.
>>>
>>>      
>>>        jdk9-build
>>>        
>>>          9
>>>        
>>>        
>>>          
>>>            
>>>              maven-surefire-plugin
>>>              
>>>                -Djava.locale.providers=COMPAT
>>>              
>>>            
>>>          
>>>        
>>>      
>>>
>>> I'm not sure if I can help more, but if you need more info just let me
>>> know.
>>>
>>> Andreas
>>>
>>> 2017-09-27 19:10 GMT+02:00 Gary Gregory :
>>>
>>> Using git master and 'mvn clean verify', on Windows 10, with Java 7, I

>>> get
>>>
 44 failures, and I think this is all/mostly hash code problems.

 With Java 8, all tests pass.

 With Java 9, I get ONE failure: ListIteratorWrapperTest.testRemove:116
 ╗
 ServiceConfiguration sun.util.locale

 If I checkout the 4.1 tag and use Java 7, I get 44 failures. ARG! What

>>> the
>>>
 heck?

 Gary



 On Mon, Sep 25, 2017 at 12:02 PM, Benedikt Ritter 
 wrote:

 Hi,
>
> who can help with the test failures on Windows? I’d like to push out
>
 the
>>>
 next release soon to get Collections Java 9 ready. I don’t have access
>
 to a

> Windows installation and I don’t feel like debugging inside a VM :o)
>
> Regards,
> Benedikt
>
>
>
> ---

[GitHub] commons-collections issue #28: COLLECTIONS-661: fix for concurrency issue in...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-collections/pull/28
  

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

Coverage increased (+0.008%) to 85.126% when pulling 
**6e8951ed0325abe3e07e32aded0b27aacdbc1011 on kinow:COLLECTIONS-661** into 
**1d21a49c27d9eab8d02785a783fcfba387a3e8e1 on apache:master**.



---

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

[GitHub] commons-collections pull request #28: COLLECTIONS-661: fix for concurrency i...

[kinow]

GitHub user kinow opened a pull request:

https://github.com/apache/commons-collections/pull/28

COLLECTIONS-661: fix for concurrency issue in HashSetValuedHashMapTest

The `getMap()` method, when testing a `HashSetValuedHashMap`, would return 
an object of this type. Which is an instance of `SetValuedMap`.

Running it in debug mode would - most of the times - run the tests and 
succeed. Running normally - especially on Windows - would result in 
intermittent, but very frequent, failures.

The `getMap()` method sometimes, depending on the order and execution of 
tests, will be null. So the collection added to the map will be either a 
`Hashset`, or a `Arrays$ArrayList`. When the types are different, `hashCode()` 
and `equals()` calls return incorrect values, resulting in the errors we have 
seen in COLLECTIONS-661.

A good solution would be to re-design the tests. The 
`TestMultiValuedMapAsMap` is testing `MultiValuedMap`'s, which include 
`HashSetValuedHashMap`. However, some of its methods contain extra logic for 
when the type under test has some characteristics like being an instance of 
`SetValuedMap`.

It might be possible to come up with a better design, where there are 
multiple test classes, for `MultiValuedMap`'s that use `SetValuedMap`'s; 
`MultieValuedMap`'s that use `List`'s, and so it goes.

Or we could add a class to the parent class, with a flag defining the type 
under test. For now, I have used the `makeObject()` method, which returns the 
collection under test. Then I validate its instance type. There is also a 
comment above the code to indicate why we are using `makeObject()` and not 
`getMap()`.

It was a fun ticket. Happy to get feedback on better solutions, or feel 
free to edit this pull request if you have right to it, or merge if you are 
happy and it has gathered some consensus.

Cheers,
Bruno

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

$ git pull https://github.com/kinow/commons-collections COLLECTIONS-661

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

https://github.com/apache/commons-collections/pull/28.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 #28


commit 6e8951ed0325abe3e07e32aded0b27aacdbc1011
Author: Bruno P. Kinoshita 
Date:   2017-10-11T07:27:25Z

COLLECTIONS-661: fix for concurrency issue in HashSetValuedHashMapTest




---

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