[VOTE][CANCEL] Release Commons Imaging 1.0-alpha1 based on RC1
I am canceling this VOTE. Need to re-roll another release candidate to fix the file signatures, following the new requirements. Will roll a new RC this week. Thanks Bruno From: Gary Gregory To: Commons Developers List ; Bruno P. Kinoshita Sent: Monday, 29 October 2018 2:35 AM Subject: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1 Hello Bruno, Thank you for preparing the RC. MD5 and SHA1 are no longer acceptable per Apache for our dist server. Please use SHA256 or SHA512. Our Commons release plugin will create those for you. Nexus has different requirements and that is fine for now. Gary On Sun, Oct 28, 2018, 04:58 Bruno P. Kinoshita wrote: We have fixed quite a few bugs and added some significant enhancements since Sanselan 0.97-incubator was released, >so I would like to release Apache Commons Imaging 1.0-alpha1. > >This will be the first release after the project was renamed from Sanselan to >Apache Commons Imaging. This is an alpha >release candidate. > >Apache Commons Imaging 1.0-alpha RC1 is available for review here: >https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/ (svn >revision 30460) > >The Git tag commons-imaging-1.0-alpha1-RC1 commit for this RC is >44f4b12dc3f5131944a9c147e1a8f0dc18360806 which you can browse here: > >https://git-wip-us.apache.org/repos/asf?p=commons-imaging.git;a=tag;h=refs/tags/commons-imaging-1.0-alpha1-RC1 > >Maven artifacts are here: >https://repository.apache.org/content/repositories/orgapachecommons-1393/ > >These are the Maven artifacts and their hashes > >commons-imaging-1.0-alpha1-javadoc.jar >(SHA1: 0f6c64af7dd7099024c5ecd9fd2632db04b1d719) >commons-imaging-1.0-alpha1-sources.jar >(SHA1: 12734288eca62bc87ac3b8efc77d66c80cd9a310) >commons-imaging-1.0-alpha1-test-sources.jar >(SHA1: 415cd0ff4af1c69d39b35c907ef29180ce4a03d6) >commons-imaging-1.0-alpha1-tests.jar >(SHA1: 9704b79c446e2a5b1f6c4ff7c09ac5a0383326af) >commons-imaging-1.0-alpha1.jar >(SHA1: b39f13c05550327501224cd2cbd02591c59a8bbb) >commons-imaging-1.0-alpha1.pom >(SHA1: 03697c87b9e18b5c69946712c31c3fd85cdde1ee) > >I have tested this with 8 using Maven 3.5.4 on Ubuntu LTS. > >Details of changes for 1.0-alpha1 are in the release notes: >https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/RELEASE-NOTES.txt >http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/changes-report.html > >Site: >http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/index.html >(note some *relative* links are broken and the 1.2 directories are >not yet created - these will be OK once the site is deployed) > >RAT Report: >http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-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 04:00 UTC 31-March 2010 > >[ ] +1 Release these artifacts >[ ] +0 OK, but... >[ ] -0 OK, but really should fix... >[ ] -1 I oppose this release because... > >Thanks! > >Bruno > >- >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: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1)
Will cancel the vote tonight, thanks for spotting that @Gary. @Rob, thanks a lot for all the great work on the new plugin. I might be able to roll a new RC tonight, or during this week. Would you have a pointer to the some page with the commands I have to run to properly use the plugin and upload the right binaries and signatures, please? Not in a hurry to cut the release, so if you are planning to write the docs this week, I'd be happy to review/try them for the imaging RC2. Thanks heaps Bruno From: Rob Tompkins To: Commons Developers List Cc: Bruno P. Kinoshita Sent: Monday, 29 October 2018 2:49 AM Subject: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1) This is mildly on me for not updating the release docs recently. I’ll put that on my docket for the week. PS. @Bruno solid work and many thanks for rolling the RC. Cheers, -Rob > On Oct 28, 2018, at 9:35 AM, Gary Gregory wrote: > > Hello Bruno, > > Thank you for preparing the RC. > > MD5 and SHA1 are no longer acceptable per Apache for our dist server. > Please use SHA256 or SHA512. Our Commons release plugin will create those > for you. Nexus has different requirements and that is fine for now. > > Gary > >> On Sun, Oct 28, 2018, 04:58 Bruno P. Kinoshita wrote: >> >> We have fixed quite a few bugs and added some significant enhancements >> since Sanselan 0.97-incubator was released, >> so I would like to release Apache Commons Imaging 1.0-alpha1. >> >> This will be the first release after the project was renamed from Sanselan >> to Apache Commons Imaging. This is an alpha >> release candidate. >> >> Apache Commons Imaging 1.0-alpha RC1 is available for review here: >> https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/ >> (svn revision 30460) >> >> The Git tag commons-imaging-1.0-alpha1-RC1 commit for this RC is >> 44f4b12dc3f5131944a9c147e1a8f0dc18360806 which you can browse here: >> >> >> https://git-wip-us.apache.org/repos/asf?p=commons-imaging.git;a=tag;h=refs/tags/commons-imaging-1.0-alpha1-RC1 >> >> Maven artifacts are here: >> https://repository.apache.org/content/repositories/orgapachecommons-1393/ >> >> These are the Maven artifacts and their hashes >> >> commons-imaging-1.0-alpha1-javadoc.jar >> (SHA1: 0f6c64af7dd7099024c5ecd9fd2632db04b1d719) >> commons-imaging-1.0-alpha1-sources.jar >> (SHA1: 12734288eca62bc87ac3b8efc77d66c80cd9a310) >> commons-imaging-1.0-alpha1-test-sources.jar >> (SHA1: 415cd0ff4af1c69d39b35c907ef29180ce4a03d6) >> commons-imaging-1.0-alpha1-tests.jar >> (SHA1: 9704b79c446e2a5b1f6c4ff7c09ac5a0383326af) >> commons-imaging-1.0-alpha1.jar >> (SHA1: b39f13c05550327501224cd2cbd02591c59a8bbb) >> commons-imaging-1.0-alpha1.pom >> (SHA1: 03697c87b9e18b5c69946712c31c3fd85cdde1ee) >> >> I have tested this with 8 using Maven 3.5.4 on Ubuntu LTS. >> >> Details of changes for 1.0-alpha1 are in the release notes: >> >> https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/RELEASE-NOTES.txt >> >> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/changes-report.html >> >> Site: >> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/index.html >> (note some *relative* links are broken and the 1.2 directories are >> not yet created - these will be OK once the site is deployed) >> >> RAT Report: >> >> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-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 04:00 UTC 31-March 2010 >> >> [ ] +1 Release these artifacts >> [ ] +0 OK, but... >> [ ] -0 OK, but really should fix... >> [ ] -1 I oppose this release because... >> >> Thanks! >> >> Bruno >> >> - >> 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 Apache Commons Configuration 2.4 based on RC2
Building from tag works fine with `mvn clean test site` on Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T20:58:13+13:00) Maven home: /opt/apache-maven-3.5.2 Java version: 1.8.0_172, vendor: Oracle Corporation Java home: /opt/jdk1.8.0_172/jre Default locale: en_NZ, platform encoding: UTF-8 OS name: "linux", version: "4.15.0-38-generic", arch: "amd64", family: "unix" No blockers found in the site reports. Clirr has one error about a new method NodeModel getNodeModel() added. Not sure if worth mentioning in RELEASE-NOTES.txt, or if that's not a problem as it's just a new method. Heaps of new errors in Checkstyle, but didn't have time to investigate if that was caused due to some upgrade in the version of the checkstyle-plugin, addition of new rules, or if new code was introduced with the errors. easy to fix, good opportunity for new contributors. Couldn't check signatures or do a more thorough validation, but from what I could see it looks good. [ X ] +1 Release these artifacts Thank you for RM'ing, sorry for not being able to check the mailing list much lately. Bruno From: Gary Gregory To: Commons Developers List Sent: Monday, 29 October 2018 3:35 AM Subject: Re: [VOTE] Release Apache Commons Configuration 2.4 based on RC2 May at least one more PMC member review this release candidate please? Gary On Tue, Oct 23, 2018 at 8:10 PM Rob Tompkins wrote: > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons Configuration 2.3 was released, so I would like to > release Apache Commons Configuration 2.4. > > Apache Commons Configuration 2.4 RC2 is available for review here: >https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2 > (svn revision 30260) > > The Subversion tag for this RC is here: > > http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_4_RC2/ > (svn revision 1844715) > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1391/org/apache/commons/commons-configuration2/2.4/ > > These are the Maven artifacts and their hashes in Nexus: > > #Nexus SHA-1s > > commons-configuration2-2.4-sources.jar=2bcdd60dac93e16b53f613f37979b585cb5c23ec > commons-configuration2-2.4.pom=24b3e7ef8afc470ead058236dd71a73a0f029d9d > > commons-configuration2-2.4-test-sources.jar=1f1fc7fad84049f55a6b9f28e9cacde46971bad6 > > commons-configuration2-2.4-tests.jar=a6c0ef84d06fb110681ee4ffc46f8d2d0436d203 > > commons-configuration2-2.4-javadoc.jar=e73305477e5d62ad0e140b58aa7e87dd0dbd1266 > commons-configuration2-2.4.jar=208279841cb092e0f51f097c1f1649341e6333f3 > > #Release SHA-256s > #Tue Oct 23 21:49:00 EDT 2018 > > commons-configuration2-2.4-bin-tar.gz=25a59714dbeb379263d5b05d88a22ce0a6521cbd4b29e0d43630e8375cbb2776 > > commons-configuration2-2.4-bin-zip=cb9b1979ec07dbfb7ffc8b1a4e897210942ab85e8c91fcaba0a2de88fad274cd > > commons-configuration2-2.4-src-tar.gz=1c24b4a507a7688e26af3b508eb85cf954a92ac3dc2ffa841bb114c345fb2d97 > > commons-configuration2-2.4-src-zip=d6ac9d51fb29426746916265c072e370a2b1a3720c8891bba8621720c3f479c8 > > I have tested this with 'mvn clean install site' using: > Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; > 2018-06-17T14:33:14-04:00) > Maven home: /usr/local/Cellar/maven/3.5.4/libexec > Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac" > > Details of changes since 2.3 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site > (note some *relative* links are broken and the 2.4 directories are not > yet created - these will be OK once the site is deployed.) > > CLIRR Report (compared to 2.3): > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site/clirr-report.html > > JApiCmp Report (compared to 2.3): > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site/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. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Rob Tompkins, > Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314) > - > To unsubscribe, e-mail: dev-unsub
Re: commons-io Java version
Just post a message here. Gary On Sun, Oct 28, 2018, 15:07 Aleksander Ściborek < aleksanderscibo...@gmail.com> wrote: > Hi, so if I want to suggest that common-io should be bumped who I should > contant with? > > > On Wed, 17 Oct 2018 at 19:07, Gary Gregory wrote: > > > Hi, > > > > We are all volunteers here, so it's up to a PMC member to step up and > > volunteer. > > > > Gary > > > > On Wed, Oct 17, 2018 at 11:01 AM Aleksander Ściborek < > > aleksanderscibo...@gmail.com> wrote: > > > > > Hi, i see that java version commons-io is 1.7. Is there any plan to > bump > > > it to 1.8? > > > Recently the version of commons-lang was updated > > > Aleksander > > > > > >
Re: commons-io Java version
That mail was enough, all People with time on their Hands read the dev list. Gruss Bernd -- http://bernd.eckenfels.net Von: Aleksander Ściborek Gesendet: Sonntag, 28. Oktober 2018 22:07 An: Commons Developers List Betreff: Re: commons-io Java version Hi, so if I want to suggest that common-io should be bumped who I should contant with? On Wed, 17 Oct 2018 at 19:07, Gary Gregory wrote: > Hi, > > We are all volunteers here, so it's up to a PMC member to step up and > volunteer. > > Gary > > On Wed, Oct 17, 2018 at 11:01 AM Aleksander Ściborek < > aleksanderscibo...@gmail.com> wrote: > > > Hi, i see that java version commons-io is 1.7. Is there any plan to bump > > it to 1.8? > > Recently the version of commons-lang was updated > > Aleksander > > >
Re: commons-io Java version
Hi, so if I want to suggest that common-io should be bumped who I should contant with? On Wed, 17 Oct 2018 at 19:07, Gary Gregory wrote: > Hi, > > We are all volunteers here, so it's up to a PMC member to step up and > volunteer. > > Gary > > On Wed, Oct 17, 2018 at 11:01 AM Aleksander Ściborek < > aleksanderscibo...@gmail.com> wrote: > > > Hi, i see that java version commons-io is 1.7. Is there any plan to bump > > it to 1.8? > > Recently the version of commons-lang was updated > > Aleksander > > >
[parent] release 48 soonish
Hi All: It would be nice to release parent 48 soon which includes: org.jacoco:jacoco-maven-plugin 0.8.1 -> 0.8.2 (Java 11) This let's us use JaCoCo on Java 11. Gary
Re: [CONFIGURATION] 2.4 RC2 test failures with java 11 (Was: [VOTE] Release Apache Commons Configuration 2.4 based on RC2)
I updated from EasyMock 3.6 to 4.0, but now there is a different, problem, see the same https://github.com/easymock/easymock/issues/230 Gary On Fri, Oct 26, 2018 at 1:57 PM Gary Gregory wrote: > Feel free to comment here: https://github.com/easymock/easymock/issues/230 > > On Fri, Oct 26, 2018 at 11:39 AM Gary Gregory > wrote: > >> Indeed: >> >> java.lang.IllegalArgumentException: Unsupported class file major version >> 55 >> at org.easymock.asm.ClassReader.(ClassReader.java:166) >> at org.easymock.asm.ClassReader.(ClassReader.java:148) >> at org.easymock.asm.ClassReader.(ClassReader.java:136) >> at org.easymock.asm.ClassReader.(ClassReader.java:237) >> at >> org.easymock.cglib.proxy.BridgeMethodResolver.resolveAll(BridgeMethodResolver.java:69) >> at org.easymock.cglib.proxy.Enhancer.emitMethods(Enhancer.java:1132) >> at org.easymock.cglib.proxy.Enhancer.generateClass(Enhancer.java:630) >> at >> org.easymock.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25) >> at >> org.easymock.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:329) >> at org.easymock.cglib.proxy.Enhancer.generate(Enhancer.java:492) >> at >> org.easymock.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:93) >> at >> org.easymock.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:91) >> at >> org.easymock.cglib.core.internal.LoadingCache$2.call(LoadingCache.java:54) >> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >> at >> org.easymock.cglib.core.internal.LoadingCache.createEntry(LoadingCache.java:61) >> at org.easymock.cglib.core.internal.LoadingCache.get(LoadingCache.java:34) >> at >> org.easymock.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:116) >> at >> org.easymock.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:291) >> at org.easymock.cglib.proxy.Enhancer.createHelper(Enhancer.java:480) >> at org.easymock.cglib.proxy.Enhancer.createClass(Enhancer.java:337) >> at >> org.easymock.internal.ClassProxyFactory.createProxy(ClassProxyFactory.java:175) >> at org.easymock.internal.MocksControl.createMock(MocksControl.java:123) >> at org.easymock.internal.MocksControl.createMock(MocksControl.java:99) >> at org.easymock.EasyMock.mock(EasyMock.java:69) >> at org.easymock.EasyMock.createMock(EasyMock.java:311) >> at >> org.apache.commons.configuration2.reloading.TestFileHandlerReloadingDetector.testRefreshIsReloadingRequiredTrue(TestFileHandlerReloadingDetector.java:131) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at >> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) >> at >> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >> at >> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) >> at >> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >> at >> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) >> at >> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) >> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) >> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) >> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >> at >> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89) >> at >> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463) >> at >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209) >> >> Gary >> >> On Fri, Oct 26, 2018 at 10:55 AM Pascal Schumacher < >> pascalschumac...@gmx.net> wrote: >> >>> I would guess this is caused by a byte code manipulation library like >>> ASM which does not support Java 11 yet. >>> >>> Am 26.10.2018 um 16:28 schrieb Rob Tompkins: >>> > Yes…those failures happen in 11, but not 10. Thoughts? >>> > >>> >> On Oct 26, 2018, at 9:59 AM, Gary Gregory >>> wrote: >>> >> >>> >> Ping? Anybo
Re: [pool] how to move to Java8?
Perhaps a path forward would be: 1) Release 2.6.1 now as is. 2) Update to Java 8 for 2.7. I am OK with jumping to 2) over 1) That would be up to the RM volunteering for this ;-) Gary On Sun, Oct 28, 2018 at 7:36 AM Gary Gregory wrote: > +1 for Java 8. > > Gary > > On Sun, Oct 28, 2018, 06:13 Romain Manni-Bucau > wrote: > >> +1 to move to java 8, java 7 is more than outdated today even for legacy >> systems >> >> Le dim. 28 oct. 2018 12:10, Mark Struberg a >> écrit : >> >> > Hi folks! >> > I've worked through the open POOL tickets and found a few tickets which >> > would like to enhance a few of our interfaces. >> > E.g. in POOL-355 we have a request to add a new method getMaxNumActive() >> > to the ObjectPool interface. >> > Now this would of course be a backward compatibility breaking change. If >> > we would have java8 as minimum then we could easily just add a default >> > method which returns -1. But since our min Java version is 1.7 we are >> > doomed... >> > I would love to get the deadlock fixes out with the current 1.7 >> > requirement first. Because that's important to get to the people >> (including >> > my own customers). >> > But what after that?Would this justify a commons-pool-3.0?Do we also >> like >> > to cleanup other stuff? Or should we just raise our min Java >> requirement to >> > 1.8 and call it 2.7? >> > I'm totally fine either way and would love to get any feedback. >> > >> > LieGrue,strub >> > >> > >> > >> >
Re: [VOTE] Release Apache Commons Configuration 2.4 based on RC2
May at least one more PMC member review this release candidate please? Gary On Tue, Oct 23, 2018 at 8:10 PM Rob Tompkins wrote: > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons Configuration 2.3 was released, so I would like to > release Apache Commons Configuration 2.4. > > Apache Commons Configuration 2.4 RC2 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2 > (svn revision 30260) > > The Subversion tag for this RC is here: > > http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_4_RC2/ > (svn revision 1844715) > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1391/org/apache/commons/commons-configuration2/2.4/ > > These are the Maven artifacts and their hashes in Nexus: > > #Nexus SHA-1s > > commons-configuration2-2.4-sources.jar=2bcdd60dac93e16b53f613f37979b585cb5c23ec > commons-configuration2-2.4.pom=24b3e7ef8afc470ead058236dd71a73a0f029d9d > > commons-configuration2-2.4-test-sources.jar=1f1fc7fad84049f55a6b9f28e9cacde46971bad6 > > commons-configuration2-2.4-tests.jar=a6c0ef84d06fb110681ee4ffc46f8d2d0436d203 > > commons-configuration2-2.4-javadoc.jar=e73305477e5d62ad0e140b58aa7e87dd0dbd1266 > commons-configuration2-2.4.jar=208279841cb092e0f51f097c1f1649341e6333f3 > > #Release SHA-256s > #Tue Oct 23 21:49:00 EDT 2018 > > commons-configuration2-2.4-bin-tar.gz=25a59714dbeb379263d5b05d88a22ce0a6521cbd4b29e0d43630e8375cbb2776 > > commons-configuration2-2.4-bin-zip=cb9b1979ec07dbfb7ffc8b1a4e897210942ab85e8c91fcaba0a2de88fad274cd > > commons-configuration2-2.4-src-tar.gz=1c24b4a507a7688e26af3b508eb85cf954a92ac3dc2ffa841bb114c345fb2d97 > > commons-configuration2-2.4-src-zip=d6ac9d51fb29426746916265c072e370a2b1a3720c8891bba8621720c3f479c8 > > I have tested this with 'mvn clean install site' using: > Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; > 2018-06-17T14:33:14-04:00) > Maven home: /usr/local/Cellar/maven/3.5.4/libexec > Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac" > > Details of changes since 2.3 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site > (note some *relative* links are broken and the 2.4 directories are not > yet created - these will be OK once the site is deployed.) > > CLIRR Report (compared to 2.3): > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site/clirr-report.html > > JApiCmp Report (compared to 2.3): > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site/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. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Rob Tompkins, > Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314) > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[VOTE][CANCEL] Release Apache Commons Pool 2.6.1 based on RC1
I am canceling this VOTE. It is stale and I've not taken the time to look into the tagging issue. Furthermore, there are additional fixes that have just come in. Gary On Thu, Aug 23, 2018 at 7:39 AM Gary Gregory wrote: > > > On Wed, Aug 22, 2018 at 1:14 PM Benedikt Ritter > wrote: > >> Hi Gary, >> Am Mi., 22. Aug. 2018 um 16:04 Uhr schrieb Gary Gregory < >> garydgreg...@gmail.com>: >> >> > WRT signing tags, ATM, I cannot git's -s option to work with GPG on >> > Windows. Any clues? >> > >> >> Sorry, I'm on macOS. For that to work I needed to have the gpg-agent >> running. But I don't know whether this is a unix thing. >> >> The tag signing alone would not cause me to vote -1. I can live with an >> unsigned tag. What really needs to be fixed are the differences between >> src >> distribution and release tag in my opinion. I'll have time on Saturday to >> have a look into that if you don't get to it until then. >> > > I welcome the help :-) Quite busy at work. > > Gary > >> >> Regards, >> Benedikt >> >> >> > >> > Gary >> > >> > On Tue, Aug 21, 2018 at 1:06 AM Benedikt Ritter >> > wrote: >> > >> > > Hello Gary, >> > > >> > > -1, I there are several issues that we need to fix this before we can >> > > release 2.6.1. >> > > >> > > I think the RELEASE NOTES need more work: >> > > >> > > "The Apache Commons Pool team is pleased to announce the release of >> > Apache >> > > Commons Pool 2.6.1-SNAPSHOT." >> > > "No client code changes are required to migrate from versions 2.0-2.3 >> to >> > > version 2.4.3." - what about migration to 2.6.1? >> > > "Version 2 requires JDK level 1.6 or above" - Website states that >> Java 7 >> > is >> > > required. >> > > >> > > The release tag is not signed: >> > > ~/w/a/r/p/commons-pool git:(master) > git tag -v >> commons-pool-2.6.1-RC1 >> > > object 87c5dc14a967a70dd6e640395d4e842b021cdb8f >> > > type commit >> > > tag commons-pool-2.6.1-RC1 >> > > tagger Gary Gregory 1534517006 -0600 >> > > >> > > Tag Apache Commons Pool release 2.6.1 RC1 >> > > error: no signature found >> > > >> > > There are various differences between to release tag in git and the >> > > contents of the src archive: >> > > ~/w/a/r/pool-2.6.1 > diff -rq commons-pool commons-pool2-2.6.1-src >> > > Only in commons-pool: .git >> > > Only in commons-pool: .gitignore >> > > Only in commons-pool: .travis.yml >> > > Only in commons-pool: CONTRIBUTING.md >> > > Files commons-pool/NOTICE.txt and commons-pool2-2.6.1-src/NOTICE.txt >> > differ >> > > Only in commons-pool: README.md >> > > Files commons-pool/RELEASE-NOTES.txt and >> > > commons-pool2-2.6.1-src/RELEASE-NOTES.txt differ >> > > Files commons-pool/pom.xml and commons-pool2-2.6.1-src/pom.xml differ >> > > Only in commons-pool: pool-RC.sh >> > > Only in commons-pool: pool-pre-RC.sh >> > > Only in commons-pool: pool-release.sh >> > > Only in commons-pool/src: assembly >> > > Files commons-pool/src/changes/changes.xml and >> > > commons-pool2-2.6.1-src/src/changes/changes.xml differ >> > > Files commons-pool/src/site/resources/download_pool.cgi and >> > > commons-pool2-2.6.1-src/src/site/resources/download_pool.cgi differ >> > > Files commons-pool/src/site/site.xml and >> > > commons-pool2-2.6.1-src/src/site/site.xml differ >> > > Files commons-pool/src/site/xdoc/index.xml and >> > > commons-pool2-2.6.1-src/src/site/xdoc/index.xml differ >> > > Files commons-pool/src/site/xdoc/issue-tracking.xml and >> > > commons-pool2-2.6.1-src/src/site/xdoc/issue-tracking.xml differ >> > > >> > > Some of them are okay (e.g. git files) but others are not (like >> > > changes.xml) >> > > >> > > The build works on my machine using: >> > > ~/w/a/r/p/commons-pool2-2.6.1-src > mvn -version >> > > Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; >> > > 2018-06-17T20:33:14+02:00) >> > > Maven home: /usr/local/Cellar/maven/3.5.4/libexec >> > > Java version: 1.8.0_161, vendor: Oracle Corporation, runtime: >> > > /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre >> > > Default locale: de_DE, platform encoding: UTF-8 >> > > OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac" >> > > >> > > Regards, >> > > Benedikt >> > > >> > > Am Fr., 17. Aug. 2018 um 18:08 Uhr schrieb Gary Gregory < >> > > ggreg...@apache.org >> > > >: >> > > >> > > > We have fixed one bug and updated optional dependencies since Apache >> > > > Commons Pool 2.6.0 was released, so I would like to release Apache >> > > Commons >> > > > Pool 2.6.1. >> > > > >> > > > Apache Commons Pool 2.6.1 RC1 is available for review here: >> > > > https://dist.apache.org/repos/dist/dev/commons/pool/2.6.1-RC1 >> (svn >> > > > revision 28810) >> > > > >> > > > The Git tag commons-pool-2.6.1-RC1 commit for this RC is >> > > > 87c5dc14a967a70dd6e640395d4e842b021cdb8f which you can browse here: >> > > > >> > > > >> > > > >> > > >> > >> https://git-wip-us.apache.org/repos/asf?p=commons-pool.git;a=tag;h=refs/tags/commons-pool-2.6.1-RC1 >> > > > >> > > > Maven artifacts are here: >> >
[site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1)
This is mildly on me for not updating the release docs recently. I’ll put that on my docket for the week. PS. @Bruno solid work and many thanks for rolling the RC. Cheers, -Rob > On Oct 28, 2018, at 9:35 AM, Gary Gregory wrote: > > Hello Bruno, > > Thank you for preparing the RC. > > MD5 and SHA1 are no longer acceptable per Apache for our dist server. > Please use SHA256 or SHA512. Our Commons release plugin will create those > for you. Nexus has different requirements and that is fine for now. > > Gary > >> On Sun, Oct 28, 2018, 04:58 Bruno P. Kinoshita wrote: >> >> We have fixed quite a few bugs and added some significant enhancements >> since Sanselan 0.97-incubator was released, >> so I would like to release Apache Commons Imaging 1.0-alpha1. >> >> This will be the first release after the project was renamed from Sanselan >> to Apache Commons Imaging. This is an alpha >> release candidate. >> >> Apache Commons Imaging 1.0-alpha RC1 is available for review here: >> https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/ >> (svn revision 30460) >> >> The Git tag commons-imaging-1.0-alpha1-RC1 commit for this RC is >> 44f4b12dc3f5131944a9c147e1a8f0dc18360806 which you can browse here: >> >> >> https://git-wip-us.apache.org/repos/asf?p=commons-imaging.git;a=tag;h=refs/tags/commons-imaging-1.0-alpha1-RC1 >> >> Maven artifacts are here: >> https://repository.apache.org/content/repositories/orgapachecommons-1393/ >> >> These are the Maven artifacts and their hashes >> >> commons-imaging-1.0-alpha1-javadoc.jar >> (SHA1: 0f6c64af7dd7099024c5ecd9fd2632db04b1d719) >> commons-imaging-1.0-alpha1-sources.jar >> (SHA1: 12734288eca62bc87ac3b8efc77d66c80cd9a310) >> commons-imaging-1.0-alpha1-test-sources.jar >> (SHA1: 415cd0ff4af1c69d39b35c907ef29180ce4a03d6) >> commons-imaging-1.0-alpha1-tests.jar >> (SHA1: 9704b79c446e2a5b1f6c4ff7c09ac5a0383326af) >> commons-imaging-1.0-alpha1.jar >> (SHA1: b39f13c05550327501224cd2cbd02591c59a8bbb) >> commons-imaging-1.0-alpha1.pom >> (SHA1: 03697c87b9e18b5c69946712c31c3fd85cdde1ee) >> >> I have tested this with 8 using Maven 3.5.4 on Ubuntu LTS. >> >> Details of changes for 1.0-alpha1 are in the release notes: >> >> https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/RELEASE-NOTES.txt >> >> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/changes-report.html >> >> Site: >> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/index.html >> (note some *relative* links are broken and the 1.2 directories are >> not yet created - these will be OK once the site is deployed) >> >> RAT Report: >> >> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-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 04:00 UTC 31-March 2010 >> >> [ ] +1 Release these artifacts >> [ ] +0 OK, but... >> [ ] -0 OK, but really should fix... >> [ ] -1 I oppose this release because... >> >> Thanks! >> >> Bruno >> >> - >> 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: [pool] how to move to Java8?
+1 for Java 8. Gary On Sun, Oct 28, 2018, 06:13 Romain Manni-Bucau wrote: > +1 to move to java 8, java 7 is more than outdated today even for legacy > systems > > Le dim. 28 oct. 2018 12:10, Mark Struberg a > écrit : > > > Hi folks! > > I've worked through the open POOL tickets and found a few tickets which > > would like to enhance a few of our interfaces. > > E.g. in POOL-355 we have a request to add a new method getMaxNumActive() > > to the ObjectPool interface. > > Now this would of course be a backward compatibility breaking change. If > > we would have java8 as minimum then we could easily just add a default > > method which returns -1. But since our min Java version is 1.7 we are > > doomed... > > I would love to get the deadlock fixes out with the current 1.7 > > requirement first. Because that's important to get to the people > (including > > my own customers). > > But what after that?Would this justify a commons-pool-3.0?Do we also like > > to cleanup other stuff? Or should we just raise our min Java requirement > to > > 1.8 and call it 2.7? > > I'm totally fine either way and would love to get any feedback. > > > > LieGrue,strub > > > > > > >
Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1
Hello Bruno, Thank you for preparing the RC. MD5 and SHA1 are no longer acceptable per Apache for our dist server. Please use SHA256 or SHA512. Our Commons release plugin will create those for you. Nexus has different requirements and that is fine for now. Gary On Sun, Oct 28, 2018, 04:58 Bruno P. Kinoshita wrote: > We have fixed quite a few bugs and added some significant enhancements > since Sanselan 0.97-incubator was released, > so I would like to release Apache Commons Imaging 1.0-alpha1. > > This will be the first release after the project was renamed from Sanselan > to Apache Commons Imaging. This is an alpha > release candidate. > > Apache Commons Imaging 1.0-alpha RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/ > (svn revision 30460) > > The Git tag commons-imaging-1.0-alpha1-RC1 commit for this RC is > 44f4b12dc3f5131944a9c147e1a8f0dc18360806 which you can browse here: > > > https://git-wip-us.apache.org/repos/asf?p=commons-imaging.git;a=tag;h=refs/tags/commons-imaging-1.0-alpha1-RC1 > > Maven artifacts are here: > https://repository.apache.org/content/repositories/orgapachecommons-1393/ > > These are the Maven artifacts and their hashes > > commons-imaging-1.0-alpha1-javadoc.jar > (SHA1: 0f6c64af7dd7099024c5ecd9fd2632db04b1d719) > commons-imaging-1.0-alpha1-sources.jar > (SHA1: 12734288eca62bc87ac3b8efc77d66c80cd9a310) > commons-imaging-1.0-alpha1-test-sources.jar > (SHA1: 415cd0ff4af1c69d39b35c907ef29180ce4a03d6) > commons-imaging-1.0-alpha1-tests.jar > (SHA1: 9704b79c446e2a5b1f6c4ff7c09ac5a0383326af) > commons-imaging-1.0-alpha1.jar > (SHA1: b39f13c05550327501224cd2cbd02591c59a8bbb) > commons-imaging-1.0-alpha1.pom > (SHA1: 03697c87b9e18b5c69946712c31c3fd85cdde1ee) > > I have tested this with 8 using Maven 3.5.4 on Ubuntu LTS. > > Details of changes for 1.0-alpha1 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/RELEASE-NOTES.txt > > http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/changes-report.html > > Site: > http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/index.html > (note some *relative* links are broken and the 1.2 directories are > not yet created - these will be OK once the site is deployed) > > RAT Report: > > http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-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 04:00 UTC 31-March 2010 > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thanks! > > Bruno > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [pool] how to move to Java8?
+1 to move to java 8, java 7 is more than outdated today even for legacy systems Le dim. 28 oct. 2018 12:10, Mark Struberg a écrit : > Hi folks! > I've worked through the open POOL tickets and found a few tickets which > would like to enhance a few of our interfaces. > E.g. in POOL-355 we have a request to add a new method getMaxNumActive() > to the ObjectPool interface. > Now this would of course be a backward compatibility breaking change. If > we would have java8 as minimum then we could easily just add a default > method which returns -1. But since our min Java version is 1.7 we are > doomed... > I would love to get the deadlock fixes out with the current 1.7 > requirement first. Because that's important to get to the people (including > my own customers). > But what after that?Would this justify a commons-pool-3.0?Do we also like > to cleanup other stuff? Or should we just raise our min Java requirement to > 1.8 and call it 2.7? > I'm totally fine either way and would love to get any feedback. > > LieGrue,strub > > >
[pool] how to move to Java8?
Hi folks! I've worked through the open POOL tickets and found a few tickets which would like to enhance a few of our interfaces. E.g. in POOL-355 we have a request to add a new method getMaxNumActive() to the ObjectPool interface. Now this would of course be a backward compatibility breaking change. If we would have java8 as minimum then we could easily just add a default method which returns -1. But since our min Java version is 1.7 we are doomed... I would love to get the deadlock fixes out with the current 1.7 requirement first. Because that's important to get to the people (including my own customers). But what after that?Would this justify a commons-pool-3.0?Do we also like to cleanup other stuff? Or should we just raise our min Java requirement to 1.8 and call it 2.7? I'm totally fine either way and would love to get any feedback. LieGrue,strub
[VOTE] Release Commons Imaging 1.0-alpha1 based on RC1
We have fixed quite a few bugs and added some significant enhancements since Sanselan 0.97-incubator was released, so I would like to release Apache Commons Imaging 1.0-alpha1. This will be the first release after the project was renamed from Sanselan to Apache Commons Imaging. This is an alpha release candidate. Apache Commons Imaging 1.0-alpha RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/ (svn revision 30460) The Git tag commons-imaging-1.0-alpha1-RC1 commit for this RC is 44f4b12dc3f5131944a9c147e1a8f0dc18360806 which you can browse here: https://git-wip-us.apache.org/repos/asf?p=commons-imaging.git;a=tag;h=refs/tags/commons-imaging-1.0-alpha1-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1393/ These are the Maven artifacts and their hashes commons-imaging-1.0-alpha1-javadoc.jar (SHA1: 0f6c64af7dd7099024c5ecd9fd2632db04b1d719) commons-imaging-1.0-alpha1-sources.jar (SHA1: 12734288eca62bc87ac3b8efc77d66c80cd9a310) commons-imaging-1.0-alpha1-test-sources.jar (SHA1: 415cd0ff4af1c69d39b35c907ef29180ce4a03d6) commons-imaging-1.0-alpha1-tests.jar (SHA1: 9704b79c446e2a5b1f6c4ff7c09ac5a0383326af) commons-imaging-1.0-alpha1.jar (SHA1: b39f13c05550327501224cd2cbd02591c59a8bbb) commons-imaging-1.0-alpha1.pom (SHA1: 03697c87b9e18b5c69946712c31c3fd85cdde1ee) I have tested this with 8 using Maven 3.5.4 on Ubuntu LTS. Details of changes for 1.0-alpha1 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/RELEASE-NOTES.txt http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/changes-report.html Site: http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/index.html (note some *relative* links are broken and the 1.2 directories are not yet created - these will be OK once the site is deployed) RAT Report: http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-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 04:00 UTC 31-March 2010 [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Bruno - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [imaging] Questions about the 1.0-alpha release
Thanks Gary. Had a bit of spare time today, so tried preparing a new release as alpha1. Still have a few questions from last e-mail pending, but will call the vote anyway and just re-roll a rc2 later if necessary. >- RELEASE-NOTES.txt is still saying 1.0... should it be 1.0-alpha? >- What else would need to be updated? The site perhaps??? Or is it OK to have >a few places showing 1.0? Vote e-mail coming in a few minutes (hopefully). Cheers Bruno From: Gary Gregory To: Commons Developers List ; Bruno P. Kinoshita Sent: Sunday, 9 September 2018 1:47 AM Subject: Re: [imaging] Questions about the 1.0-alpha release I would call it "alpha1" instead of just "alpha". Gary On Sat, Sep 8, 2018, 06:58 Bruno P. Kinoshita wrote: Hi all, > >I am almost done following the docs to prepare a release. Didn't struggle as >much as I expected with the release-plugin. Had more trouble getting the >MANIFEST.MF entries corrected. > >But now, before I create the dist tag, and upload the zip/tar.gz (this was not >executed by the release plugin because... it's a project that uses assembly >plugin I think), I would like to confirm a few things > >- The version release is 1.0-alpha >- The changes.xml is for 1.0. I found that commons-lang appears to have had a >3.0-beta. The changes.xml contains the entries for 3.0, with an HTML comment >showing which changes were added post 3.0-beta. So I did the same for imaging >- RELEASE-NOTES.txt is still saying 1.0... should it be 1.0-alpha? >- What else would need to be updated? The site perhaps??? Or is it OK to have >a few places showing 1.0? > >I have time to work on the RC1 vote until Monday NZ time this week. So if I >manage to get these points sorted, we might be able to call the RC1 vote, and >leave it running until the next weekend - or cancel it during the week in case >of an error, and then I could prepare RC2 next weekend I think. > > >Thanks! >Bruno > >- >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: [numbers] Making fractions VALJOs
As the author of the blog and term VALJO, here are some comments on Fraction: You should use `of()` (overloading allowed) when the factory normally succeeds. You should use `from` (overloading allowed) when the factory methods are performing a conversion and have a reasonable chance of failure. The `int` methods should use `of`. The `double` methods could use either, it is a judgement call as top whether it is a conversion or a construction (does it normally succeed or not). Looking at this code https://git-wip-us.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=commons-numbers-fraction/src/main/java/org/apache/commons/numbers/fraction/Fraction.java;h=308f93033853ca8815663c576f7c38e6770dc3c3;hb=HEAD In the `abs()` method, there is no need for a local variable - just return from each branch of the if statement or use a ternary. The method order in the class is strange. I would recommend putting the getters first. I would also recommend grouping the methods compareTo, equals, hashCode and toString in that order at the end of the class. See `LocalDate` for example. The order of the static constants is also strange - I'm sure a more logical order could be chosen. The method `getReducedFraction` is not a getter, so it should not start with `get`. Maybe `ofReduced()` ? Alternatively, have an instance method `reduced()` that can be called on any fraction, so users do `of(2, 4).reduce()`. The recommended naming approach for methods on immutable VALJO classes is to use the past tense: multiply -> multipliedBy divide -> dividedBy add -> plus subtract -> minus negate -> negated No doubt this would apply widely in the project HTH Stephen On Thu, 18 Oct 2018 at 11:45, Gilles wrote: > > On Wed, 17 Oct 2018 16:33:58 -0700, Eric Barnhill wrote: > > Oh right, that is the convention. I knew there was something off. > > > > As far as you understand, is to within VALJO standards to overload > > factory > > methods, > > I don't think that it is ValJO-related; method overload is a > feature, so better use it rather than duplicate what the compiler > can do by itself. ;-) > > Gilles > > > so long as they are not private constructors? All that is > > specified on the page is that VALJOs must have all constructors > > private. So > > I am not sure whether it is in the spirit of VALJOs to overload, but > > coming > > up with elaborate names for each constructor doesn't seem like a very > > streamlined coding practice. > > > > On Tue, Oct 16, 2018 at 5:56 PM Gilles > > wrote: > > > >> On Tue, 16 Oct 2018 16:55:02 -0700, Eric Barnhill wrote: > >> > The Fraction class is IMO looking good (in better shape than > >> Complex > >> > was > >> > in) and is already quite close to fulfilling the standards for a > >> > VALJO. > >> > Equals() and CompareTo() are well designed and consistent. I see > >> two > >> > missing steps. The easy one is a parse() method which mirrors the > >> > toString() method. The harder one is the wide range of public > >> > constructors. > >> > > >> > To be a VALJO all constructors must be private and accessed with > >> > static > >> > factory methods. If these factory methods themselves can be > >> > overloaded, I > >> > think a decent schema emerges: > >> > > >> > current constructor -> proposed factory method > >> > > >> > public Fraction(double value) -> public fromDouble(double value) > >> > public Fraction(double value, double epsilon, int maxIterations) > >> -> > >> > public > >> > fromDouble(double value, double epsilon, int maxIterations) > >> > public Fraction(double value,int maxDenominator) -> public > >> > fromDouble > >> > (double value,int maxDenominator) > >> > public Fraction(int value) -> public fromInt(int value) > >> > public Fraction(int num, int denom) -> public fromInt(int num, int > >> > denom) > >> > >> Why not call them all "of(...)" ? > >> > >> Gilles > >> > >> > > >> > so this is what I propose to go with. > >> > > >> > If disambiguation in the double cases is still a problem, the > >> second > >> > and > >> > third of the double constructors could be fromDoubleEpsMaxInt and > >> > fromDoubleMaxDenom . > >> > > >> > Eric > >> > > >> > > >> > On Thu, Oct 11, 2018 at 7:00 AM Gilles > >> > >> > wrote: > >> > > >> >> On Wed, 10 Oct 2018 16:18:50 -0700, Eric Barnhill wrote: > >> >> > I am interested in moving forward on making the Fraction > >> classes > >> >> > VALJOs > >> >> > [NUMBERS-75]. > >> >> > > >> >> > Just a preliminary question for now, are we otherwise happy > >> with > >> >> the > >> >> > Fraction class in the context of commons-numbers? Or should I > >> look > >> >> > around > >> >> > for any odd behaviors leftover from commons-math (Complex had a > >> >> lot > >> >> > of > >> >> > those) that might also be improved? > >> >> > >> >> AFAIK, there was no in-depth review as was done for "Complex". > >> >> So it would indeed be quite useful to check what the Javadoc > >> >> states, whether it seems acce
[GitHub] commons-pool pull request #16: POOL-355: Add maxNumActive flag to pool imple...
GitHub user graben opened a pull request: https://github.com/apache/commons-pool/pull/16 POOL-355: Add maxNumActive flag to pool implementations You can merge this pull request into a Git repository by running: $ git pull https://github.com/graben/commons-pool POOL-355 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-pool/pull/16.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 #16 commit f9ed0f3041b2f2668e5683cce0068d6fd3b454fd Author: Benjamin Graf Date: 2018-10-25T18:04:28Z POOL-355: Add maxNumActive flag to pool implementations --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
