Re: [CONFIGURATION] 2.4 RC2 test failures with java 11 (Was: [VOTE] Release Apache Commons Configuration 2.4 based on RC2)
Note that as of EasyMock 4.0.1, our Java 11 problems are no longer. Details are here: https://github.com/easymock/easymock/issues/230#issuecomment-434065370 I've updated svn trunk to EasyMock 4.0.1. Gary On Sun, Oct 28, 2018 at 9:15 AM Gary Gregory wrote: > 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
Re: [numbers] Making fractions VALJOs
You are indeed and thank you very much for this feedback! I gave up on pushing fraction through GitHub and have pushed my first round of changes via Apache. They are available on the branch fraction-dev for inspection. I will incorporate the rest of your suggestions on my next iteration. Eric On Sun, Oct 28, 2018 at 1:52 AM Stephen Colebourne wrote: > 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
[GitHub] commons-text issue #91: TEXT-127 Detect when a variable is unknown in String...
Github user coveralls commented on the issue: https://github.com/apache/commons-text/pull/91 [](https://coveralls.io/builds/19787137) Coverage increased (+0.002%) to 97.876% when pulling **60bed4374a2db82bc7842d3ccd33e2158d2b80f6 on drajakumar:master** into **6c3cc5239c2143256976c9e8a05dd76b31c74baf on apache:master**. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-text pull request #91: TEXT-127 Detect when a variable is unknown in...
GitHub user drajakumar opened a pull request: https://github.com/apache/commons-text/pull/91 TEXT-127 Detect when a variable is unknown in StringSubstitutor You can merge this pull request into a Git repository by running: $ git pull https://github.com/drajakumar/commons-text master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-text/pull/91.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 #91 commit d3bfb518ccde125b45b9d7a874cf717321578e7f Author: Don Jeba Date: 2018-10-29T18:05:19Z TEXT-127 Detect when a variable is unknown in StringSubstitutor --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-io pull request #68: Output all parameters in ReversedLinesFileReade...
GitHub user august782 opened a pull request: https://github.com/apache/commons-io/pull/68 Output all parameters in ReversedLinesFileReaderTestParamFile In ReversedLinesFileReaderTestParamFile, the parameterized tests have three parameters, but currently the test class is configured to only output the first two. Outputting only the first two parameters is not enough to distinguish the different parameterized tests, particularly for the ones whose first two parameters are "test-file-utf8-win-linebr.bin", "UTF-8". The proposed fix is to output all three parameters as part of the reporting of the tests. You can merge this pull request into a Git repository by running: $ git pull https://github.com/august782/commons-io fix-parameterized-test-names Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-io/pull/68.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 #68 commit 0b6bf96849953186b3de7cd81d3b918d1980f7db Author: August Shi Date: 2018-10-29T17:28:22Z Changing to output all parameters for parameterized tests to distinguish them --- - 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?
I'm fine with sticking with Java 7 for Tomcat as long as the Jenkins build continues to work properly. Keep an eye on the JDKs available! ;) On Mon, 29 Oct 2018 at 10:28, Gary Gregory wrote: > changes.xml is hand crafted and used to generate parts of the site. > > Gary > > On Mon, Oct 29, 2018 at 9:26 AM Mark Struberg > wrote: > > > Yes, was not sure whether the changes.xml is generated or hand crafted. > > Gonna add the missing bits. > > > > > > LieGrue, > > strub > > > > > Am 29.10.2018 um 16:17 schrieb Gary Gregory : > > > > > > My view is to skip POOL-355 and release the current code still, on Java > > > 7, as 2.6.1, or 2.7.0 if a new feature has been added, which is not > clear > > > since it seems changes.xml has not been updated for the commits over > the > > > last week or two. > > > > > > Gary > > > > > > On Mon, Oct 29, 2018 at 6:49 AM Mark Struberg > > > > > > wrote: > > > > > >> I've went through the list and pretty much the only ticket which was > > left > > >> to really benefit from it would be the getMaxNumActive() (POOL-355). > > >> But as noted there: after a bit of thinking through it I'm even > tempted > > to > > >> close it as won't fix. Having just a bare maxNumActive doesn't give > you > > >> much info in real production. > > >> What you need is really a time graph with the currently active > > >> connections. You usually don't care about just a short spike e.g. > > because > > >> the underlying db gets restarted. What you care about is whether the > > >> connections are fine NOW and at which timeframe they have been in a > bad > > >> shape. > > >> > > >> If you (and others) could also take a look on this ticket them we > could > > go > > >> on and close it. Which whould then remove the need for Java8. > > >> > > >> That means I'm perfectly fine with keeping it java7 for now. Plus we > > also > > >> know what to take care of if we really need to bump to j8. > > >> > > >> LieGrue, > > >> strub > > >> > > >> > > >>> Am 29.10.2018 um 09:35 schrieb Mark Thomas : > > >>> > > >>> On 28/10/18 11:09, Mark Struberg wrote: > > 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. > > >>> > > >>> Tomcat 8 (with a spec required minimum Java version of Java 7) is > > >>> currently using the latest version of pool. This version of Tomcat is > > >>> unlikely to be EOL until well into the 2020s. It would be easier if > > pool > > >>> stayed on Java 7 (since we maintain a package renamed copy of the > code) > > >>> but I appreciate that that is not practical for pool for that > > timescale. > > >>> > > >>> It isn't a huge amount of work to handle things like default methods. > > >>> The Tomcat community would certainly appreciate it if any Java 8 > > >>> specific changes in Pool kept in mind that Tomcat will need to > > back-port > > >>> them to Java 7. > > >>> > > >>> Mark > > >>> > > >>> - > > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >>> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > >> > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Matt Sicker
Re: [pool] how to move to Java8?
changes.xml is hand crafted and used to generate parts of the site. Gary On Mon, Oct 29, 2018 at 9:26 AM Mark Struberg wrote: > Yes, was not sure whether the changes.xml is generated or hand crafted. > Gonna add the missing bits. > > > LieGrue, > strub > > > Am 29.10.2018 um 16:17 schrieb Gary Gregory : > > > > My view is to skip POOL-355 and release the current code still, on Java > > 7, as 2.6.1, or 2.7.0 if a new feature has been added, which is not clear > > since it seems changes.xml has not been updated for the commits over the > > last week or two. > > > > Gary > > > > On Mon, Oct 29, 2018 at 6:49 AM Mark Struberg > > > wrote: > > > >> I've went through the list and pretty much the only ticket which was > left > >> to really benefit from it would be the getMaxNumActive() (POOL-355). > >> But as noted there: after a bit of thinking through it I'm even tempted > to > >> close it as won't fix. Having just a bare maxNumActive doesn't give you > >> much info in real production. > >> What you need is really a time graph with the currently active > >> connections. You usually don't care about just a short spike e.g. > because > >> the underlying db gets restarted. What you care about is whether the > >> connections are fine NOW and at which timeframe they have been in a bad > >> shape. > >> > >> If you (and others) could also take a look on this ticket them we could > go > >> on and close it. Which whould then remove the need for Java8. > >> > >> That means I'm perfectly fine with keeping it java7 for now. Plus we > also > >> know what to take care of if we really need to bump to j8. > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 29.10.2018 um 09:35 schrieb Mark Thomas : > >>> > >>> On 28/10/18 11:09, Mark Struberg wrote: > 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. > >>> > >>> Tomcat 8 (with a spec required minimum Java version of Java 7) is > >>> currently using the latest version of pool. This version of Tomcat is > >>> unlikely to be EOL until well into the 2020s. It would be easier if > pool > >>> stayed on Java 7 (since we maintain a package renamed copy of the code) > >>> but I appreciate that that is not practical for pool for that > timescale. > >>> > >>> It isn't a huge amount of work to handle things like default methods. > >>> The Tomcat community would certainly appreciate it if any Java 8 > >>> specific changes in Pool kept in mind that Tomcat will need to > back-port > >>> them to Java 7. > >>> > >>> Mark > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [pool] how to move to Java8?
Yes, was not sure whether the changes.xml is generated or hand crafted. Gonna add the missing bits. LieGrue, strub > Am 29.10.2018 um 16:17 schrieb Gary Gregory : > > My view is to skip POOL-355 and release the current code still, on Java > 7, as 2.6.1, or 2.7.0 if a new feature has been added, which is not clear > since it seems changes.xml has not been updated for the commits over the > last week or two. > > Gary > > On Mon, Oct 29, 2018 at 6:49 AM Mark Struberg > wrote: > >> I've went through the list and pretty much the only ticket which was left >> to really benefit from it would be the getMaxNumActive() (POOL-355). >> But as noted there: after a bit of thinking through it I'm even tempted to >> close it as won't fix. Having just a bare maxNumActive doesn't give you >> much info in real production. >> What you need is really a time graph with the currently active >> connections. You usually don't care about just a short spike e.g. because >> the underlying db gets restarted. What you care about is whether the >> connections are fine NOW and at which timeframe they have been in a bad >> shape. >> >> If you (and others) could also take a look on this ticket them we could go >> on and close it. Which whould then remove the need for Java8. >> >> That means I'm perfectly fine with keeping it java7 for now. Plus we also >> know what to take care of if we really need to bump to j8. >> >> LieGrue, >> strub >> >> >>> Am 29.10.2018 um 09:35 schrieb Mark Thomas : >>> >>> On 28/10/18 11:09, Mark Struberg wrote: 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. >>> >>> Tomcat 8 (with a spec required minimum Java version of Java 7) is >>> currently using the latest version of pool. This version of Tomcat is >>> unlikely to be EOL until well into the 2020s. It would be easier if pool >>> stayed on Java 7 (since we maintain a package renamed copy of the code) >>> but I appreciate that that is not practical for pool for that timescale. >>> >>> It isn't a huge amount of work to handle things like default methods. >>> The Tomcat community would certainly appreciate it if any Java 8 >>> specific changes in Pool kept in mind that Tomcat will need to back-port >>> them to Java 7. >>> >>> Mark >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] how to move to Java8?
My view is to skip POOL-355 and release the current code still, on Java 7, as 2.6.1, or 2.7.0 if a new feature has been added, which is not clear since it seems changes.xml has not been updated for the commits over the last week or two. Gary On Mon, Oct 29, 2018 at 6:49 AM Mark Struberg wrote: > I've went through the list and pretty much the only ticket which was left > to really benefit from it would be the getMaxNumActive() (POOL-355). > But as noted there: after a bit of thinking through it I'm even tempted to > close it as won't fix. Having just a bare maxNumActive doesn't give you > much info in real production. > What you need is really a time graph with the currently active > connections. You usually don't care about just a short spike e.g. because > the underlying db gets restarted. What you care about is whether the > connections are fine NOW and at which timeframe they have been in a bad > shape. > > If you (and others) could also take a look on this ticket them we could go > on and close it. Which whould then remove the need for Java8. > > That means I'm perfectly fine with keeping it java7 for now. Plus we also > know what to take care of if we really need to bump to j8. > > LieGrue, > strub > > > > Am 29.10.2018 um 09:35 schrieb Mark Thomas : > > > > On 28/10/18 11:09, Mark Struberg wrote: > >> 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. > > > > Tomcat 8 (with a spec required minimum Java version of Java 7) is > > currently using the latest version of pool. This version of Tomcat is > > unlikely to be EOL until well into the 2020s. It would be easier if pool > > stayed on Java 7 (since we maintain a package renamed copy of the code) > > but I appreciate that that is not practical for pool for that timescale. > > > > It isn't a huge amount of work to handle things like default methods. > > The Tomcat community would certainly appreciate it if any Java 8 > > specific changes in Pool kept in mind that Tomcat will need to back-port > > them to Java 7. > > > > Mark > > > > - > > 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: [RESULT][VOTE] Release Apache Commons Configuration 2.4 based on RC2
Thank you Rob for shepherding this release! Gary On Mon, Oct 29, 2018 at 5:35 AM Rob Tompkins wrote: > This [VOTE] thread passes with votes from (in order of appearance): > > Gary Gregory: +1, > Rob Tompkins: +1, and > Bruno Kinoshita: +1. > > I will perform the release activities now and will send the release > announcement tomorrow. > > Many thanks for the validations, > -Rob > > > > On Oct 23, 2018, at 10: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 > >
Re: [VOTE][CANCEL] Release Apache Commons Pool 2.6.1 based on RC1
Hi Mark, I think you should give RM'ing a shot. We have a nice new release plugin that helps a lot. Rob is planning on refining the Commons release docs, if he has not already done so. Gary On Mon, Oct 29, 2018, 01:02 Mark Struberg wrote: > Txs gary! > > When will there be a new reelase run? > > If it's worth I could also do the release manager IF the project is > properly set up. > Means if it's a straight forward maven release then I gonna run it the > same as my other dozen ASF projects. > > LieGrue, > strub > > > > Am 28.10.2018 um 15:29 schrieb Gary Gregory : > > > > 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.
Re: [pool] how to move to Java8?
I've went through the list and pretty much the only ticket which was left to really benefit from it would be the getMaxNumActive() (POOL-355). But as noted there: after a bit of thinking through it I'm even tempted to close it as won't fix. Having just a bare maxNumActive doesn't give you much info in real production. What you need is really a time graph with the currently active connections. You usually don't care about just a short spike e.g. because the underlying db gets restarted. What you care about is whether the connections are fine NOW and at which timeframe they have been in a bad shape. If you (and others) could also take a look on this ticket them we could go on and close it. Which whould then remove the need for Java8. That means I'm perfectly fine with keeping it java7 for now. Plus we also know what to take care of if we really need to bump to j8. LieGrue, strub > Am 29.10.2018 um 09:35 schrieb Mark Thomas : > > On 28/10/18 11:09, Mark Struberg wrote: >> 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. > > Tomcat 8 (with a spec required minimum Java version of Java 7) is > currently using the latest version of pool. This version of Tomcat is > unlikely to be EOL until well into the 2020s. It would be easier if pool > stayed on Java 7 (since we maintain a package renamed copy of the code) > but I appreciate that that is not practical for pool for that timescale. > > It isn't a huge amount of work to handle things like default methods. > The Tomcat community would certainly appreciate it if any Java 8 > specific changes in Pool kept in mind that Tomcat will need to back-port > them to Java 7. > > Mark > > - > 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)
> On Oct 29, 2018, at 7:24 AM, Rob Tompkins wrote: > > > >> On Oct 28, 2018, at 8:04 PM, Bruno P. Kinoshita wrote: >> >> 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. > > I’ll try to work on this this morning (UTC-4) both on the [site] as well as > sending the details over to you. Hey Bruno, Since you’re using [parent] version 47, you should be most the way there. I, on the preparing releases page, added the needed configurations: http://commons.apache.org/releases/prepare.html#Configure_the_Build_and_Release_Plugin_to_Generate_a_Complete_Set_of_Release_Artifacts From there you should simply be able to run mvn -Duser.name= -Prelease -Ptest-deploy clean test package site deploy to test the deployment (test SVN dist commit ends up in ./target/commons-release-plugin/scm), and mvn -Duser.name= -Prelease clean test package site deploy to run the deployment (assuming that your settings.xml has sufficient privileges). Note, this is also covered here: http://commons.apache.org/releases/prepare.html#Create_the_Release_Candidate_with_the_Commons_Release_Plugin. IMPORTANT: to get the svn distribution commit to properly work, make sure that https://dist.apache.org/repos/dist/dev/commons/imaging/ is completely empty. Feel free to ping me on slack if anything arises. I do know that we’re 14 hours different in terms of timezones though. Cheers, -Rob > > -Rob > >> >> >> >> 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
[RESULT][VOTE] Release Apache Commons Configuration 2.4 based on RC2
This [VOTE] thread passes with votes from (in order of appearance): Gary Gregory: +1, Rob Tompkins: +1, and Bruno Kinoshita: +1. I will perform the release activities now and will send the release announcement tomorrow. Many thanks for the validations, -Rob > On Oct 23, 2018, at 10: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
Re: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1)
> On Oct 28, 2018, at 8:04 PM, Bruno P. Kinoshita wrote: > > 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. I’ll try to work on this this morning (UTC-4) both on the [site] as well as sending the details over to you. -Rob > > > > 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: [pool] how to move to Java8?
On 28/10/18 11:09, Mark Struberg wrote: > 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. Tomcat 8 (with a spec required minimum Java version of Java 7) is currently using the latest version of pool. This version of Tomcat is unlikely to be EOL until well into the 2020s. It would be easier if pool stayed on Java 7 (since we maintain a package renamed copy of the code) but I appreciate that that is not practical for pool for that timescale. It isn't a huge amount of work to handle things like default methods. The Tomcat community would certainly appreciate it if any Java 8 specific changes in Pool kept in mind that Tomcat will need to back-port them to Java 7. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][CANCEL] Release Apache Commons Pool 2.6.1 based on RC1
Txs gary! When will there be a new reelase run? If it's worth I could also do the release manager IF the project is properly set up. Means if it's a straight forward maven release then I gonna run it the same as my other dozen ASF projects. LieGrue, strub > Am 28.10.2018 um 15:29 schrieb Gary Gregory : > > 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
