Re: [VOTE] Release Apache Commons Pool 2.6.1 based on RC1
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 : > 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: > > > https://repository.apache.org/content/repositories/orgapachecommons-1370/org/apache/commons/commons-pool2/2.6.1/ > > These are the Maven artifacts and their hashes in Nexus: > > #Release SHA-256s > #Fri Aug 17 09:52:45 MDT 2018 > > commons-pool2-2.6.1-bin-zip.asc=c557973fdb9b917eb9bd3aea01db5ec1fd9ba81dc44de3ebbfcf0d30d3034457 > > commons-pool2-2.6.1-src-tar.gz=2c9a0cd9ca5d78321139abf66bf63bfdffab4e2c84949220efc836bab14925fb > > commons-pool2-2.6.1-sources-java-source=9ec444a335d22398db9e2b8cff08651bb200b9a43be70603ee864a69698d70a1 > > commons-pool2-2.6.1-bin-tar.gz.asc=420d24c516e0a85461f4b723f26b3d1004f5891fe35eeb221438f1bebc529697 > > commons-pool2-2.6.1-src-zip=1039a4c88929549e5bb859443a02bf65679d94fd2722c8da2b0b116f737157ed > > commons-pool2-2.6.1-bin-tar.gz=0e136611fcd6475cef0604c63901a64169af674e0a4bdc3eb6bdfd3f9974e189 > > commons-pool2-2.6.1-sources-jar.asc=b2d7c010ac17fa8c25b1a07c964774e520170b293d7280257dae730a7e6f273c > > commons-pool2-2.6.1-src-tar.gz.asc=e5101573bb01aef53d69dc4161b0ce39629cc8a8029edf20eda8b591acba9ff0 > > commons-pool2-2.6.1-bin-zip=9c67aebafbbe9a6937f51fd88dee2c5bf2b2bb38391faf866cf2c0ec1d0144b2 > > commons-pool2-2.6.1-tests-jar.asc=1aff7c2d2482c8ad8abfbdbf5a5e6e2a2d6842f5ff3812b83de53dc78139101f > > commons-pool2-2.6.1-javadoc-jar.asc=627815d18443a31a0965209c23f4c38f7a4f252983db8adbf5766c4e744070a4 > > commons-pool2-2.6.1-pom.asc=53303ad02b290d2d7740f4b322c8f3c3de1cab273fccd56afe487d161d827b3a > > commons-pool2-2.6.1-jar.asc=48c226b9cecd68c3ff4b745ccc5279fceb3feb537483ed0c5b81ef29ae95ec4b > > commons-pool2-2.6.1-tests-test-jar=54a0e606fbd469582b0b87ee61ebb5fd05b2895cd70649ce61b4a759528880a8 > > commons-pool2-2.6.1-javadoc-javadoc=246788c13a31585bf53d937ab5689d6553dd317b120919e65e0851ace5cd0e1e > > commons-pool2
[CSV] Inconsistent record separator behavior
Hi, we have this strange handling of record separator / line endings in CSV: Users can use what ever character sequence they like as a record separator. I could for example use the ! character to mark the end of a record. Then we have CSVPrinter.printComment(String). This inserts comments into a CSV output. It detects CRLF and call println() on the CSVFormat, which in turn uses the record separator to indicate a new record... So now I'm thinking: Does it make sense to use anything else but LF or CRLF as record separator? Maybe we should deprecate CSVFormat.recordSeparator(String) and introduce a LineEnding enum where users can choose between LF and CRLF. This way we can make the behavior between parsing and printing consistent. Thoughts? Benedikt
Re: [LANG] Minimum required Java version for 3.9
+1 Am 20. August 2018 19:09:27 MESZ schrieb Benedikt Ritter : >Hi, > >any objections against raising the minimum required Java version for >lang >3.9 to Java 1.8? > >Regards, >Benedikt
Re: [all] Sebb's bulk JIRA issue transition don't send email no longer works
This seems to be fixed now. I’m guessing that infra did a permissions change that accommodates us to now uncheck the box that sends all the emails on bulk change. -Rob > On Aug 14, 2018, at 11:00 AM, Gilles wrote: > > On Tue, 14 Aug 2018 15:07:15 +0100, sebb wrote: >> No idea, please ask Infra >> >> On 14 August 2018 at 14:50, Rob Tompkins wrote: >>> @Sebb with this new version of Jira, I couldn’t find your checkbox to not >>> send email notifications on the bulk transition. Do you know if it still >>> exists? >>> >>> -Rob > > It's the last option (checked in by default) in the > "step 3" (edit) panel. > > Gilles > > > - > 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: [LANG] Minimum required Java version for 3.9
Do you have specific new features or deprecations in mind to accompany the bump? Matt On Tue, Aug 21, 2018, 7:00 AM Pascal Schumacher wrote: > +1 > > Am 20. August 2018 19:09:27 MESZ schrieb Benedikt Ritter < > brit...@apache.org>: > >Hi, > > > >any objections against raising the minimum required Java version for > >lang > >3.9 to Java 1.8? > > > >Regards, > >Benedikt >
[GitHub] commons-validator pull request #12: VALIDATOR-446 extract ISSN from EAN-13
GitHub user alcole opened a pull request: https://github.com/apache/commons-validator/pull/12 VALIDATOR-446 extract ISSN from EAN-13 You can merge this pull request into a Git repository by running: $ git pull https://github.com/alcole/commons-validator alex/VALIDATOR-446/ISSN-EAN13 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-validator/pull/12.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 #12 commit 3c62546bb9712d8613fc9bc0d57359b1dbf09677 Author: alex-cole Date: 2018-08-21T18:14:12Z VALIDATOR-446 extract ISSN from EAN-13 --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-validator pull request #12: VALIDATOR-446 extract ISSN from EAN-13
Github user alcole closed the pull request at: https://github.com/apache/commons-validator/pull/12 --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-validator pull request #13: validator-446
GitHub user alcole opened a pull request: https://github.com/apache/commons-validator/pull/13 validator-446 added issn extraction from ean-13 and test cases You can merge this pull request into a Git repository by running: $ git pull https://github.com/alcole/commons-validator alex/validator-446/issn-ean13 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-validator/pull/13.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #13 commit 001ceb34a469923d8b2576823bf8f774017c57a2 Author: alex-cole Date: 2018-08-21T18:57:03Z validator-446 added issn extraction from ean-13 and test cases --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-validator pull request #14: VALIDATOR-446 ISSN extraction from EAN-1...
GitHub user alcole opened a pull request: https://github.com/apache/commons-validator/pull/14 VALIDATOR-446 ISSN extraction from EAN-13 added extract to ISSNValidator and test cases also included feedback re: tidied whitespace and static import You can merge this pull request into a Git repository by running: $ git pull https://github.com/alcole/commons-validator alcole/VALIDATOR-446/issn-ean13 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-validator/pull/14.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #14 commit 36dab0147b5e23f3cae75e8b620d27915426ec86 Author: alex-cole Date: 2018-08-21T19:41:16Z VALIDATOR-446 ISSN extraction from EAN-13 added extract to ISSNValidator and test cases --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] Minimum required Java version for 3.9
Hi Matt, Am Di., 21. Aug. 2018 um 16:12 Uhr schrieb Matt Benson : > Do you have specific new features or deprecations in mind to accompany the > bump? > I'd like to add some helpers for working with java.util.Optional for example. There are most certainly more opportunities for new Lang APIs once we have access to the functional interfaces in java.util.function. java.lang.Objects and java.lang.Arrays also got some new methods in 1.8 which make methods from ObjectUtils and ArrayUtils obsolete. I also hope that we can deprecate parts of the time package because in Java 1.8 there is the new date and time API. Regards, Benedikt > > Matt > > On Tue, Aug 21, 2018, 7:00 AM Pascal Schumacher > wrote: > > > +1 > > > > Am 20. August 2018 19:09:27 MESZ schrieb Benedikt Ritter < > > brit...@apache.org>: > > >Hi, > > > > > >any objections against raising the minimum required Java version for > > >lang > > >3.9 to Java 1.8? > > > > > >Regards, > > >Benedikt > > >
Re: [LANG] Minimum required Java version for 3.9
Also, java.time classes. Gary On Tue, Aug 21, 2018 at 1:54 PM Benedikt Ritter wrote: > Hi Matt, > Am Di., 21. Aug. 2018 um 16:12 Uhr schrieb Matt Benson >: > > > Do you have specific new features or deprecations in mind to accompany > the > > bump? > > > > I'd like to add some helpers for working with java.util.Optional for > example. There are most certainly more opportunities for new Lang APIs once > we have access to the functional interfaces in java.util.function. > > java.lang.Objects and java.lang.Arrays also got some new methods in 1.8 > which make methods from ObjectUtils and ArrayUtils obsolete. > I also hope that we can deprecate parts of the time package because in Java > 1.8 there is the new date and time API. > > Regards, > Benedikt > > > > > > Matt > > > > On Tue, Aug 21, 2018, 7:00 AM Pascal Schumacher < > pascalschumac...@gmx.net> > > wrote: > > > > > +1 > > > > > > Am 20. August 2018 19:09:27 MESZ schrieb Benedikt Ritter < > > > brit...@apache.org>: > > > >Hi, > > > > > > > >any objections against raising the minimum required Java version for > > > >lang > > > >3.9 to Java 1.8? > > > > > > > >Regards, > > > >Benedikt > > > > > >
[GitHub] commons-validator pull request #15: VALIDATOR-424 LuhnCheckDigit extends Mod...
GitHub user alcole opened a pull request: https://github.com/apache/commons-validator/pull/15 VALIDATOR-424 LuhnCheckDigit extends ModulusCheckDigit You can merge this pull request into a Git repository by running: $ git pull https://github.com/alcole/commons-validator alcole/VALIDATOR-424/Luhn-ISIN Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-validator/pull/15.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 #15 commit 79dd80dc0ac2ba1d030f6c109137ebe476857354 Author: alex-cole Date: 2018-08-22T01:34:58Z VALIDATOR-424 LuhnCheckDigit extends ModulusCheckDigit --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[release-plugin] Preparing for 1.4.
I’m curious to gauge what people think here. My general thought is no breaking BC without a major version change. So, even though this is an internal component, we stick with the rules because we never know who else might be using the component, right? -Rob - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [release-plugin] Preparing for 1.4.
Well, BC is pretty binary... it seems simple to maintain BC. Javadoc, deprecate, and keep BC IMO. Gary On Tue, Aug 21, 2018, 20:04 Rob Tompkins wrote: > I’m curious to gauge what people think here. My general thought is no > breaking BC without a major version change. So, even though this is an > internal component, we stick with the rules because we never know who else > might be using the component, right? > > -Rob > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [parent] change in commons.scmPubUrl in Parent 47
Hi,
I don't understand this discussion. Changes in Commons Parent have broken
the commons-compress build. So we should either roll this changes back or
those who need the changes in commons parent should fix the commons
compress build.
Regards,
Benedikt
Am Do., 16. Aug. 2018 um 19:08 Uhr schrieb Gary Gregory <
garydgreg...@gmail.com>:
> On Thu, Aug 16, 2018 at 10:27 AM Stefan Bodewig
> wrote:
>
> > On 2018-08-16, Gary Gregory wrote:
> >
> > > I've use the release plugin a bunch without trouble. You might want to
> > see
> > > how other POMs are configured, for example [dbcp].
> >
> > The same way as Compress (no commons- prefix), I've got no idea why
> > running site-deploy should work for it.
> >
> > You use the release plugin if you only want to publish the site and not
> > cut a release?
> >
>
> I use the plugin build the dist folder (which includes a site) and generate
> the vote email text. For the real site, after the vote, I use the stock
> site-deploy goal.
>
>
> >
> > > You have to keep in mind that components like Collections, Lang, Pool,
> > and
> > > DBCP, the folder name is different from the artifact id because the
> > > artifact id contains a major version number, for example commons-lang
> is
> > > the folder but commons-lang3 is the AID.
> >
> > The parent POM says about componentId:
> >
> >
> ${project.artifactId}
>
> ${project.artifactId}
>
> For the seconds comment it should read
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
