Re: svn commit: r6522 - in /dev/commons/daemon/binaries/windows: commons-daemon-1.0.15-bin-windows-signed.zip.asc commons-daemon-1.0.15-bin-windows-signed.zip.md5 commons-daemon-1.0.15-bin-windows-sig

2014-09-15 Thread sebb
On 15 September 2014 21:58, wrote: > Author: markt > Date: Mon Sep 15 20:58:00 2014 > New Revision: 6522 > > Log: > Add hashes and sig > > Added: > > dev/commons/daemon/binaries/windows/commons-daemon-1.0.15-bin-windows-signed.zip.asc >(with props) > > dev/commons/daemon/binaries/wi

Re: svn commit: r6521 - in /dev/commons/daemon: ./ binaries/ binaries/windows/ binaries/windows/commons-daemon-1.0.15-bin-windows-signed.zip

2014-09-15 Thread sebb
On 15 September 2014 21:41, wrote: > Author: markt > Date: Mon Sep 15 20:41:21 2014 > New Revision: 6521 > > Log: > Stage Commons Daemon 1.0.15 with signed windows binaries for voting > > Added: > dev/commons/daemon/ > dev/commons/daemon/binaries/ > dev/commons/daemon/binaries/windows

Re: [VOTE] Release Apache Commons Daemon 1.0.15 windows binary package with signed executables

2014-09-15 Thread Bernd Eckenfels
Hello, +1 from me, too. (even when I am not so sure that code signing in OSS projects/upstream projects is always usefull). Gruss Bernd BTW: at my shop, we use the Eclipse CBI signing plugin (server based). http://git.eclipse.org/c/cbi/org.eclipse.cbi.maven.plugins.git/about/ Am Mon, 15 Sep 2

Re: [VOTE] Release Apache Commons Daemon 1.0.15 windows binary package with signed executables

2014-09-15 Thread Mark Thomas
On 15/09/2014 22:05, Mark Thomas wrote: > All, > > After a few teething problems with the signing service, I now have a > version of the Apache Commons Daemon 1.0.15 Windows binary distribution > where the Windows executables have been digitally signed ready for release. > > The zip is identical

[continuum] BUILD FAILURE: Apache Commons Configuration - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))

2014-09-15 Thread Apache Continuum
Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=36814&projectId=72 Build statistics: State: Failed Previous State: Failed Started at: Mon 15 Sep 2014 21:20:14 + Finished at: Mon 15 Sep 2014 21:20:36 + Total time: 21s Build Trigger: Schedule

[VOTE] Release Apache Commons Daemon 1.0.15 windows binary package with signed executables

2014-09-15 Thread Mark Thomas
All, After a few teething problems with the signing service, I now have a version of the Apache Commons Daemon 1.0.15 Windows binary distribution where the Windows executables have been digitally signed ready for release. The zip is identical to this file: https://dist.apache.org/repos/dist/relea

Re: [continuum] BUILD FAILURE: Apache Commons Configuration - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))

2014-09-15 Thread Oliver Heger
It seems that the continuum build is somehow out of sync with the SVN repository. The workspace still contains the old configuration package which has been renamed to configuration2 (now both packages exist). Does anybody know how to fix this? Thanks Oliver Am 15.09.2014 um 22:20 schrieb Apache

[continuum] BUILD FAILURE: Apache Commons Configuration - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))

2014-09-15 Thread Apache Continuum
Online report : https://continuum-ci.apache.org/continuum/buildResult.action?buildId=36811&projectId=72 Build statistics: State: Failed Previous State: Failed Started at: Mon 15 Sep 2014 20:20:18 + Finished at: Mon 15 Sep 2014 20:20:46 + Total time: 27s Build Trigger: Schedule

Re: [pool] POOL-272: per-key numTestsPerEvictionRun

2014-09-15 Thread Phil Steitz
On 9/15/14 9:02 AM, Michael Berman wrote: > I'm fine with pushing it off to 2.4, since it doesn't seem like we're > converging on an obviously preferred implementation. > > That said, I'm not too worried about maintaining the per-key iterator, even > though the key list is dynamic. The eviction pro

Re: [pool] POOL-272: per-key numTestsPerEvictionRun

2014-09-15 Thread Michael Berman
I'm fine with pushing it off to 2.4, since it doesn't seem like we're converging on an obviously preferred implementation. That said, I'm not too worried about maintaining the per-key iterator, even though the key list is dynamic. The eviction process already maintains its own list of keys, which

Re: [pool] POOL-272: per-key numTestsPerEvictionRun

2014-09-15 Thread Phil Steitz
On 9/11/14 11:39 AM, Phil Steitz wrote: > On 9/11/14 8:55 AM, Phil Steitz wrote: >> On 9/9/14 11:38 AM, Michael Berman wrote: >>> Great, thanks! I have all the new config property boilerplate in place and >>> I understand how it should work, but I'm debating the best way to implement >>> the per-ke