[VOTE] Release Apache Commons Codec 1.17.0 based on RC1
We have fixed a few bugs and added enhancements since Apache Commons Codec 1.16.1 was released, so I would like to release Apache Commons Codec 1.17.0. Apache Commons Codec 1.17.0 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/codec/1.17.0-RC1 (svn revision 68679) The Git tag commons-codec-1.17.0-RC1 commit for this RC is 5d809fe3d729bde9b507a51d2b2ed659da053692 which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=5d809fe3d729bde9b507a51d2b2ed659da053692 You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-codec.git --branch commons-codec-1.17.0-RC1 commons-codec-1.17.0-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1723/commons-codec/commons-codec/1.17.0/ These are the artifacts and their hashes: #Release SHA-512s #Sat Apr 20 18:11:51 UTC 2024 commons-codec-1.17.0-bin.tar.gz=24bb52e8260c74b7abb0e47d1634d74e35f7f8174c7ce1daec478411b16615542f9675297d2f374bba1135623e260627c5a0300e7b5c3b77309bb13a2a0fa2a9 commons-codec-1.17.0-bin.zip=6895c1282bff2cb72d64883759ed706a577afe2ebeae1474bf73473b79b67f62d39ce8025543411468a4bdfdc030dd9392f08a2c9c96d548d373edb3c7071dec commons-codec-1.17.0-bom.json=eccbb26e56f9d92ada5bf5b790cb2311eac42016ab9f77cc185f530a094a4739e0c19f26360ebe397de4f9870ab553a35cb71fcc29a2b23532de64b67e32b344 commons-codec-1.17.0-bom.xml=e74a440e5b9b4e740d8d03561925c48ce72c7596fa1ec44bea827abd245eed2efbadbaa8694d1cbef6a41cad5857070d48fc6b7addfa1857567ab17ab331d97b commons-codec-1.17.0-javadoc.jar=c89da8a94284b074e16edb41dc0a895bf2e8c5f201022e393927b634c85743c2be467b953a43e0492db0d76c7aeb9c17be96a8bac1c631536e7481817e6f6f31 commons-codec-1.17.0-sources.jar=f51dffee159b257db43d3371b4c5bc7e43729948b20f95085b0f7088c1803321fed29eaede5709404a0e17ad6a68f3f9286623af9eb2744e95dda7461f6dc956 commons-codec-1.17.0-src.tar.gz=afa4425e84cc8f2a29b4b95c5129233696180828fcb51dece8febd55d565cc53a4960f543aa430c027b96ed50768c9584b08f55f43c0a35cd22bb3126e3fbea9 commons-codec-1.17.0-src.zip=af5fc7d3c8d597729c6c90b4c6a50144a2b14432edd2741e9cbdef794a82f847952bdf7c0603ba20781cc38d0db334c435ae9acbfdefae2aea6b2226cd693e93 commons-codec-1.17.0-test-sources.jar=a8eefd6c9f5bcd8d539d1c0becd7994b8b706a25dd7cbf7c529a4533c9e51bb9ff4e7357174601e307fa3d110c7875bf096a46e83a13dcaf8324ffb03cfea860 commons-codec-1.17.0-tests.jar=caa3cbc353bca5de9c3823a5ba19950c4fe6155969bed0bdaf9d654e91c4720f2cb6c507b452148d1bb3ad6f543cb4b3b4c1f738569f619df74fbcc498c58130 commons-codec_commons-codec-1.17.0.spdx.json=728bad36fe918a0e63a6deb53d3c11d0e1c7fa0b2069ad5a46b24d0ab319819300a93e2694eabf9e19a3875141e49ebb7aea75b874d812bf40a1ec6dcc87ebbf I have tested this with 'mvn' and 'mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using: openjdk version "21.0.2" 2024-01-16 OpenJDK Runtime Environment Homebrew (build 21.0.2) OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing) Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) Maven home: /usr/local/Cellar/maven/3.9.6/libexec Java version: 21.0.2, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "14.4.1", arch: "x86_64", family: "mac" Darwin 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:11:05 PDT 2024; root:xnu-10063.101.17~1/RELEASE_X86_64 x86_64 Details of changes since 1.16.1 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/codec/1.17.0-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/codec/1.17.0-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/codec/1.17.0-RC1/site/index.html (note some *relative* links are broken and the 1.17.0 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 1.16.1): https://dist.apache.org/repos/dist/dev/commons/codec/1.17.0-RC1/site/japicmp.html RAT Report: https://dist.apache.org/repos/dist/dev/commons/codec/1.17.0-RC1/site/rat-report.html KEYS: https://downloads.apache.org/commons/KEYS Please review the release candidate and vote. This vote will close no sooner than 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, Gary Gregory, Release Manager (using key 86fdc7e2a11262cb) For following is intended as a helper and refresher for reviewers. Validating a release candidate == These guidelines are NOT complete. Requirements: Git, Java, Maven. You can validate a release from a release candidate (RC) tag as follows. 1a) Clone and checkout the RC tag git clone https://gitbox.apache.org/repos/asf/commons-codec.git --branch commons-codec-1.17.0-RC1 commons-codec-1.17.0-RC1 cd commons-codec-1.17.0-RC1 1b)
Re: [VOTE] Release Apache Commons JCS 3.2.1 based on rc2
So that's +1 (sorry for the misfired email). The Java 21 I tested is: openjdk version "21.0.2" 2024-01-16 OpenJDK Runtime Environment Homebrew (build 21.0.2) OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing) Gary On Sat, Apr 20, 2024 at 1:40 PM Gary Gregory wrote: > > Tested src zip file: > - SHA512 OK > - ASC OK > - `mvn` (default goal) OK > > Using Java 17 OK: > > openjdk version "17.0.11" 2024-04-16 > OpenJDK Runtime Environment Homebrew (build 17.0.11+0) > OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing) > > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: /usr/local/Cellar/maven/3.9.6/libexec > Java version: 17.0.11, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.4.1", arch: "x86_64", family: "mac" > > Darwin 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:11:05 > PDT 2024; root:xnu-10063.101.17~1/RELEASE_X86_64 x86_64 > > Tested with Java 21 and `mvn` (default goal): > > > Gary > > On Sat, Apr 20, 2024 at 6:25 AM Thomas Vandahl wrote: > > > > Hi folks, > > > > We have fixed a few bugs since Apache Commons JCS 3.2 was released, so I > > would like to release Apache Commons JCS 3.2.1. > > > > Apache Commons JCS 3.2.1 rc2 is available for review here: > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2 (svn > > revision 68673) > > > > The Git tag commons-jcs3-3.2.1-rc2 commit for this RC is > > a2263c39fb07410ec75cf961362f9d9371298844 which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=a2263c39fb07410ec75cf961362f9d9371298844 > > You may checkout this tag using: > > git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch > > commons-jcs3-3.2.1-rc2 commons-jcs3-3.2.1-rc2 > > > > Maven artifacts are here: > > > > https://repository.apache.org/content/repositories/orgapachecommons-1722/org/apache/commons/commons-jcs3/3.2.1/ > > > > These are the artifacts and their hashes: > > > > 20f898a3f7c41de29249d9e7e57cab754c5aa710da43c7018ce25413fa695d4edb363e036fd57884652e05ccf1e6b5946c7f4ff4b9a723affca42914e89935af > > commons-jcs3-dist-3.2.1-bin.tar.gz > > fe454deabd3311c2c7b59db7ce25db49f6ba0bccfd97bb9262e38adaeb00cbb16d6ba8542b75d816a5ca05098782cf44374d3fe0573814370923fef940d00c56 > > commons-jcs3-dist-3.2.1-bin.zip > > 7c9d912978f0f88a01e9e2a9475bd07a6c81379bb12f4a4cbdeec890899c7dbdcb6421c45c0655d28cf951f284ab32ca61d8a1aedbdad46d05bd127c060c5968 > > commons-jcs3-dist-3.2.1-src.tar.gz > > 4c513b03909fdfe9dff1e6d6689e33b8badd92f5d6d470172ad1fdfe86f0869398cc77ff2cb114db8648a332d47375c6615ac26d574fa9882b7564481cc14f72 > > commons-jcs3-dist-3.2.1-src.zip > > > > I have tested this with ***'mvn clean install site site:stage'*** using: > > -- > > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) > > Java version: 17.0.8, vendor: Oracle Corporation, runtime: > > /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home > > Default locale: de_DE, platform encoding: UTF-8 > > OS name: "mac os x", version: "11.7.10", arch: "x86_64", family: "mac" > > -- > > > > NOTE: Some JCS tests require a working multicast setup. If you get test > > failures from tests > > starting with UDPDiscovery*, make sure that your network supports multicast > > (most VPNs do not, > > for example). > > > > > > Details of changes since 3.2 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/RELEASE-NOTES.txt > > > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/changes-report.html > > > > Site: > > > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/index.html > > (note some *relative* links are broken and the 3.2.1 directories are > > not yet created - these will be OK once the site is deployed.) > > > > JApiCmp Report (compared to 3.2): > > > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/commons-jcs3-core/japicmp.html > > > > RAT Report: > > > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/commons-jcs3-core/rat-report.html > > > > KEYS: > > https://www.apache.org/dist/commons/KEYS > > > > Please review the release candidate and vote. > > This vote will close no sooner than 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, > > > > tv, > > Release Manager (using key 88817402) > > > > > > - > > 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
Re: [VOTE] Release Apache Commons JCS 3.2.1 based on rc2
Tested src zip file: - SHA512 OK - ASC OK - `mvn` (default goal) OK Using Java 17 OK: openjdk version "17.0.11" 2024-04-16 OpenJDK Runtime Environment Homebrew (build 17.0.11+0) OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing) Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) Maven home: /usr/local/Cellar/maven/3.9.6/libexec Java version: 17.0.11, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "14.4.1", arch: "x86_64", family: "mac" Darwin 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:11:05 PDT 2024; root:xnu-10063.101.17~1/RELEASE_X86_64 x86_64 Tested with Java 21 and `mvn` (default goal): Gary On Sat, Apr 20, 2024 at 6:25 AM Thomas Vandahl wrote: > > Hi folks, > > We have fixed a few bugs since Apache Commons JCS 3.2 was released, so I > would like to release Apache Commons JCS 3.2.1. > > Apache Commons JCS 3.2.1 rc2 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2 (svn > revision 68673) > > The Git tag commons-jcs3-3.2.1-rc2 commit for this RC is > a2263c39fb07410ec75cf961362f9d9371298844 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=a2263c39fb07410ec75cf961362f9d9371298844 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch > commons-jcs3-3.2.1-rc2 commons-jcs3-3.2.1-rc2 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1722/org/apache/commons/commons-jcs3/3.2.1/ > > These are the artifacts and their hashes: > > 20f898a3f7c41de29249d9e7e57cab754c5aa710da43c7018ce25413fa695d4edb363e036fd57884652e05ccf1e6b5946c7f4ff4b9a723affca42914e89935af > commons-jcs3-dist-3.2.1-bin.tar.gz > fe454deabd3311c2c7b59db7ce25db49f6ba0bccfd97bb9262e38adaeb00cbb16d6ba8542b75d816a5ca05098782cf44374d3fe0573814370923fef940d00c56 > commons-jcs3-dist-3.2.1-bin.zip > 7c9d912978f0f88a01e9e2a9475bd07a6c81379bb12f4a4cbdeec890899c7dbdcb6421c45c0655d28cf951f284ab32ca61d8a1aedbdad46d05bd127c060c5968 > commons-jcs3-dist-3.2.1-src.tar.gz > 4c513b03909fdfe9dff1e6d6689e33b8badd92f5d6d470172ad1fdfe86f0869398cc77ff2cb114db8648a332d47375c6615ac26d574fa9882b7564481cc14f72 > commons-jcs3-dist-3.2.1-src.zip > > I have tested this with ***'mvn clean install site site:stage'*** using: > -- > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) > Java version: 17.0.8, vendor: Oracle Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home > Default locale: de_DE, platform encoding: UTF-8 > OS name: "mac os x", version: "11.7.10", arch: "x86_64", family: "mac" > -- > > NOTE: Some JCS tests require a working multicast setup. If you get test > failures from tests > starting with UDPDiscovery*, make sure that your network supports multicast > (most VPNs do not, > for example). > > > Details of changes since 3.2 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/index.html > (note some *relative* links are broken and the 3.2.1 directories are not > yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.2): > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/commons-jcs3-core/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/commons-jcs3-core/rat-report.html > > KEYS: > https://www.apache.org/dist/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 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, > > tv, > Release Manager (using key 88817402) > > > - > 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 JCS 3.2.1 based on rc2
Hi Gary, > Am 20.04.2024 um 15:30 schrieb Gary D. Gregory : > > Something is wrong with at least one ASC file: > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/commons-jcs3-dist-3.2.1-src.zip.asc > > $ gpg --verify commons-jcs3-dist-3.2.1-src.zip.asc > gpg: assuming signed data in 'commons-jcs3-dist-3.2.1-src.zip' > gpg: Signature made Sat, Apr 20, 2024 05:43:52 AM EDT > gpg:using DSA key 839B8C32286C100BDB08F5522EB9468288817402 I have no idea why Maven suddenly prefers my DSA key over my RSA key. I added the former to the KEYS file. Please try again. Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: (commons-parent) branch master updated: Facilitate JMH benchmarking from the Maven CLI
I don't what would go in this new component though. The tests in the
components I looked at don't have anything to share AFAICT.
Gary
On Sat, Apr 20, 2024, 12:13 PM Gilles Sadowski wrote:
> Hi.
>
> Le sam. 20 avr. 2024 à 17:50, Gary Gregory a
> écrit :
> >
> > Hello,
> >
> > I looked at Commons Lang, Commons IO, Commons CSV, Commons BCEL, Commons
> > Crypto, and Commons Text. All of the above do the same duplicate work.
>
> For sure, it's an improvement to make duplicate configurations obsolete.
> However, shouldn't we go a step further in harmonizing the repositories'
> structure in terms of functionality?
> For example, we could have a component ("internal" to Commons" dedicated
> to benchmarking boiler-plate code (similar to, or within, the "Testing"
> project
> which you had proposed some time ago).
> As noted, IMHO a Maven module dedicated to benchmarking is preferable to
> "mixing" with unit tests (e.g. only that module would then depend on the
> benchmarking utilities).
>
> Regards,
> Gilles
>
> >
> > Gary
> >
> > On Sat, Apr 20, 2024, 11:01 AM Gilles Sadowski
> wrote:
> >
> > > Hi.
> > >
> > > This commit caught my attention but I've not looked in detail (sorry!).
> > > I'm wondering whether this addition deserves a discussion here on "dev"
> > > to reach consensus on how to handle benchmarking code in a uniform
> > > way across all components.
> > > For a long time, some components (namely and mainly "Commons
> > > RNG") have been providing[1] extensive JMH codes (in dedicated
> > > maven modules) in order to generate benchmark reports.
> > > This addition seems (?) to duplicate the functionality, under different
> > > assumptions on how to trigger it.
> > > Did you look at how the benchmarking functionality is laid out in
> [RNG]?
> > > Can't it be generalized to other components, with or without formal
> > > support in the "main" POM file? [At first sight, it would seem tidier,
> > > more
> > > flexible and more maintainable, to *not* bundle benchmark codes within
> > > "src/test" (where true unit tests reside)...]
> > >
> > > Gilles
> > >
> > > [1] Thanks to Alex.
> > >
> > > Le sam. 20 avr. 2024 à 16:30, a écrit :
> > > >
> > > > [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: (commons-parent) branch master updated: Facilitate JMH benchmarking from the Maven CLI
Hi.
Le sam. 20 avr. 2024 à 17:50, Gary Gregory a écrit :
>
> Hello,
>
> I looked at Commons Lang, Commons IO, Commons CSV, Commons BCEL, Commons
> Crypto, and Commons Text. All of the above do the same duplicate work.
For sure, it's an improvement to make duplicate configurations obsolete.
However, shouldn't we go a step further in harmonizing the repositories'
structure in terms of functionality?
For example, we could have a component ("internal" to Commons" dedicated
to benchmarking boiler-plate code (similar to, or within, the "Testing" project
which you had proposed some time ago).
As noted, IMHO a Maven module dedicated to benchmarking is preferable to
"mixing" with unit tests (e.g. only that module would then depend on the
benchmarking utilities).
Regards,
Gilles
>
> Gary
>
> On Sat, Apr 20, 2024, 11:01 AM Gilles Sadowski wrote:
>
> > Hi.
> >
> > This commit caught my attention but I've not looked in detail (sorry!).
> > I'm wondering whether this addition deserves a discussion here on "dev"
> > to reach consensus on how to handle benchmarking code in a uniform
> > way across all components.
> > For a long time, some components (namely and mainly "Commons
> > RNG") have been providing[1] extensive JMH codes (in dedicated
> > maven modules) in order to generate benchmark reports.
> > This addition seems (?) to duplicate the functionality, under different
> > assumptions on how to trigger it.
> > Did you look at how the benchmarking functionality is laid out in [RNG]?
> > Can't it be generalized to other components, with or without formal
> > support in the "main" POM file? [At first sight, it would seem tidier,
> > more
> > flexible and more maintainable, to *not* bundle benchmark codes within
> > "src/test" (where true unit tests reside)...]
> >
> > Gilles
> >
> > [1] Thanks to Alex.
> >
> > Le sam. 20 avr. 2024 à 16:30, a écrit :
> > >
> > > [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: (commons-parent) branch master updated: Facilitate JMH benchmarking from the Maven CLI
Hello,
I looked at Commons Lang, Commons IO, Commons CSV, Commons BCEL, Commons
Crypto, and Commons Text. All of the above do the same duplicate work.
Gary
On Sat, Apr 20, 2024, 11:01 AM Gilles Sadowski wrote:
> Hi.
>
> This commit caught my attention but I've not looked in detail (sorry!).
> I'm wondering whether this addition deserves a discussion here on "dev"
> to reach consensus on how to handle benchmarking code in a uniform
> way across all components.
> For a long time, some components (namely and mainly "Commons
> RNG") have been providing[1] extensive JMH codes (in dedicated
> maven modules) in order to generate benchmark reports.
> This addition seems (?) to duplicate the functionality, under different
> assumptions on how to trigger it.
> Did you look at how the benchmarking functionality is laid out in [RNG]?
> Can't it be generalized to other components, with or without formal
> support in the "main" POM file? [At first sight, it would seem tidier,
> more
> flexible and more maintainable, to *not* bundle benchmark codes within
> "src/test" (where true unit tests reside)...]
>
> Gilles
>
> [1] Thanks to Alex.
>
> Le sam. 20 avr. 2024 à 16:30, a écrit :
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ggregory pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-parent.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> > new 9637b97 Facilitate JMH benchmarking from the Maven CLI
> > 9637b97 is described below
> >
> > commit 9637b97c371906c90d958b2b7869a47818ad2e0b
> > Author: Gary Gregory
> > AuthorDate: Sat Apr 20 10:28:56 2024 -0400
> >
> > Facilitate JMH benchmarking from the Maven CLI
> >
> > - Add profile benchmark for JMH benchmarks
> > - Add JMH to dependency management section
> > ---
> > pom.xml | 46
> +-
> > src/changes/changes.xml | 3 +++
> > 2 files changed, 44 insertions(+), 5 deletions(-)
> >
> > diff --git a/pom.xml b/pom.xml
> > index abfe20e..dbb3698 100644
> > --- a/pom.xml
> > +++ b/pom.xml
> > @@ -167,7 +167,7 @@
> >
> > 6.4.1 .aQute.bndlib.version>
> > 5.10.2
> > -
> > +1.37
> >
> >java-11-up
> > @@ -1856,7 +1855,6 @@
> > 10.15.0
> >
> >
> > -
> >
> >
> >java-17-up
> > @@ -1870,7 +1868,45 @@
> > -->
> >
> >
> > -
> > +
> > +
> > + benchmark
> > +
> > +true
> > +org.apache
> > +
> > +
> > +
> > +
> > +org.codehaus.mojo
> > +exec-maven-plugin
> > +3.2.0
> > +
> > +
> > +benchmark
> > +test
> > +
> > + exec
> > +
> > +
> > + test
> > + java
> > +
> > +-classpath
> > +
> > +org.openjdk.jmh.Main
> > +-rf
> > +json
> > +-rff
> > +
> target/jmh-result.${benchmark}.json
> > +${benchmark}
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> >
> > -
> >
> > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > index a62cb49..0937e3b 100644
> > --- a/src/changes/changes.xml
> > +++ b/src/changes/changes.xml
> > @@ -58,6 +58,9 @@ The type attribute can be
> add,update,fix,remove.
> > -->
> >
> >
> > +
> > + Add
> profile benchmark for JMH benchmarks.
> > + Add
> JMH to dependency management section.
> >
> > Set
> Javadoc link to latest Java API LTS version.
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: (commons-parent) branch master updated: Facilitate JMH benchmarking from the Maven CLI
Hi.
This commit caught my attention but I've not looked in detail (sorry!).
I'm wondering whether this addition deserves a discussion here on "dev"
to reach consensus on how to handle benchmarking code in a uniform
way across all components.
For a long time, some components (namely and mainly "Commons
RNG") have been providing[1] extensive JMH codes (in dedicated
maven modules) in order to generate benchmark reports.
This addition seems (?) to duplicate the functionality, under different
assumptions on how to trigger it.
Did you look at how the benchmarking functionality is laid out in [RNG]?
Can't it be generalized to other components, with or without formal
support in the "main" POM file? [At first sight, it would seem tidier, more
flexible and more maintainable, to *not* bundle benchmark codes within
"src/test" (where true unit tests reside)...]
Gilles
[1] Thanks to Alex.
Le sam. 20 avr. 2024 à 16:30, a écrit :
>
> This is an automated email from the ASF dual-hosted git repository.
>
> ggregory pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-parent.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 9637b97 Facilitate JMH benchmarking from the Maven CLI
> 9637b97 is described below
>
> commit 9637b97c371906c90d958b2b7869a47818ad2e0b
> Author: Gary Gregory
> AuthorDate: Sat Apr 20 10:28:56 2024 -0400
>
> Facilitate JMH benchmarking from the Maven CLI
>
> - Add profile benchmark for JMH benchmarks
> - Add JMH to dependency management section
> ---
> pom.xml | 46 +-
> src/changes/changes.xml | 3 +++
> 2 files changed, 44 insertions(+), 5 deletions(-)
>
> diff --git a/pom.xml b/pom.xml
> index abfe20e..dbb3698 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -167,7 +167,7 @@
>
>
> 6.4.1
> 5.10.2
> -
> +1.37
>
>java-11-up
> @@ -1856,7 +1855,6 @@
> 10.15.0
>
>
> -
>
>
>java-17-up
> @@ -1870,7 +1868,45 @@
> -->
>
>
> -
> +
> +
> + benchmark
> +
> +true
> +org.apache
> +
> +
> +
> +
> +org.codehaus.mojo
> +exec-maven-plugin
> +3.2.0
> +
> +
> +benchmark
> +test
> +
> + exec
> +
> +
> + test
> + java
> +
> +-classpath
> +
> +org.openjdk.jmh.Main
> +-rf
> +json
> +-rff
> +target/jmh-result.${benchmark}.json
> +${benchmark}
> +
> +
> +
> +
> +
> +
> +
> +
>
> -
>
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index a62cb49..0937e3b 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -58,6 +58,9 @@ The type attribute can be add,update,fix,remove.
> -->
>
>
> +
> + Add
> profile benchmark for JMH benchmarks.
> + Add JMH
> to dependency management section.
>
> Set
> Javadoc link to latest Java API LTS version.
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.2.1 based on rc2
Something is wrong with at least one ASC file: https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/commons-jcs3-dist-3.2.1-src.zip.asc $ gpg --verify commons-jcs3-dist-3.2.1-src.zip.asc gpg: assuming signed data in 'commons-jcs3-dist-3.2.1-src.zip' gpg: Signature made Sat, Apr 20, 2024 05:43:52 AM EDT gpg:using DSA key 839B8C32286C100BDB08F5522EB9468288817402 gpg: Can't check signature: No public key The SHA512 file is OK which is good: $ shasum -a 512 commons-jcs3-dist-3.2.1-src.zip 4c513b03909fdfe9dff1e6d6689e33b8badd92f5d6d470172ad1fdfe86f0869398cc77ff2cb114db8648a332d47375c6615ac26d574fa9882b7564481cc14f72 *commons-jcs3-dist-3.2.1-src.zip $ cat commons-jcs3-dist-3.2.1-src.zip.sha512 4c513b03909fdfe9dff1e6d6689e33b8badd92f5d6d470172ad1fdfe86f0869398cc77ff2cb114db8648a332d47375c6615ac26d574fa9882b7564481cc14f72 Gary On 2024/04/20 10:25:45 Thomas Vandahl wrote: > Hi folks, > > We have fixed a few bugs since Apache Commons JCS 3.2 was released, so I > would like to release Apache Commons JCS 3.2.1. > > Apache Commons JCS 3.2.1 rc2 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2 (svn > revision 68673) > > The Git tag commons-jcs3-3.2.1-rc2 commit for this RC is > a2263c39fb07410ec75cf961362f9d9371298844 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=a2263c39fb07410ec75cf961362f9d9371298844 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch > commons-jcs3-3.2.1-rc2 commons-jcs3-3.2.1-rc2 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1722/org/apache/commons/commons-jcs3/3.2.1/ > > These are the artifacts and their hashes: > > 20f898a3f7c41de29249d9e7e57cab754c5aa710da43c7018ce25413fa695d4edb363e036fd57884652e05ccf1e6b5946c7f4ff4b9a723affca42914e89935af > commons-jcs3-dist-3.2.1-bin.tar.gz > fe454deabd3311c2c7b59db7ce25db49f6ba0bccfd97bb9262e38adaeb00cbb16d6ba8542b75d816a5ca05098782cf44374d3fe0573814370923fef940d00c56 > commons-jcs3-dist-3.2.1-bin.zip > 7c9d912978f0f88a01e9e2a9475bd07a6c81379bb12f4a4cbdeec890899c7dbdcb6421c45c0655d28cf951f284ab32ca61d8a1aedbdad46d05bd127c060c5968 > commons-jcs3-dist-3.2.1-src.tar.gz > 4c513b03909fdfe9dff1e6d6689e33b8badd92f5d6d470172ad1fdfe86f0869398cc77ff2cb114db8648a332d47375c6615ac26d574fa9882b7564481cc14f72 > commons-jcs3-dist-3.2.1-src.zip > > I have tested this with ***'mvn clean install site site:stage'*** using: > -- > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) > Java version: 17.0.8, vendor: Oracle Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home > Default locale: de_DE, platform encoding: UTF-8 > OS name: "mac os x", version: "11.7.10", arch: "x86_64", family: "mac" > -- > > NOTE: Some JCS tests require a working multicast setup. If you get test > failures from tests > starting with UDPDiscovery*, make sure that your network supports multicast > (most VPNs do not, > for example). > > > Details of changes since 3.2 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/index.html > (note some *relative* links are broken and the 3.2.1 directories are not > yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.2): > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/commons-jcs3-core/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/commons-jcs3-core/rat-report.html > > KEYS: > https://www.apache.org/dist/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 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, > > tv, > Release Manager (using key 88817402) > > > - > 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: [Collections-BloomFilter][Discuss] missing functionality?
On Sat, 20 Apr 2024 at 11:36, Claude Warren wrote:
> The LayerdBloomFilter has a method find() that returns an array of ints
> that are the indices into the layer array. This is easily reproducible
> using an iterator.
> There is also get() method that takes an integer argument (an index of the
> bloom filter) and returns the Bloom filter from the layer. This is
> reproducible but not as efficient using an iterator.
>
Note that using an iterator is how the LinkedList would do this. We are not
using an ArrayList with Order(1) retrieval time.
So performance of the current implementation here is already Order(n).
> I think the array is the proper structure.
>
If an array is the correct structure then we should type to List. Typing to
an interface allows changing the implementation with no effect on the API.
For example changing to a concurrent data structure.
The question is what is the most important functionality? Order(1) add and
remove from the head and tail of the layers (Deque) or Order(1) retrieval
of layers by depth index (List).
Re: find
It currently returns the layer index. What would you do with this other
than call get(index) to get the BloomFilter. We could support this with a
different find method:
// find each bloom filter layer that contains the IndexProducer
// API can be changed if this is required to return as soon as a filter is
found that satisfies some requirement (Predicate vs Consumer).
public void findEach(IndexProducer indexProducer, Consumer
result)
Why else do you require indices of layers? If there is no use case
other than layer retrieval then this seems to be the wrong API.
Alex
> Claude
>
> On Fri, Apr 19, 2024 at 11:06 AM Alex Herbert
> wrote:
>
> > On Fri, 19 Apr 2024 at 08:26, Claude Warren wrote:
> >
> > > While the Deque makes clear the idea of enqueueing and dequeueing the
> > > layers it does not have the method to natively traverse and extract
> > entries
> > > from the middle of the queue. Nor would I expect it to. So I think
> the
> > > Deque does not accurately reflect how the collection of Bloom filters
> is
> > > utilized.
> > >
> >
> > You can traverse and remove entries with the Iterator of the Deque:
> >
> > Deque d = new LinkedList<>();
> > d.addAll(Arrays.asList(1, 2, 3, 4, 5));
> > for (Iterator it = d.iterator(); it.hasNext();) {
> > int i = it.next();
> > if (i == 3) {
> > it.remove();
> > }
> > }
> > System.out.println(d);
> >
> > prints:
> >
> > [1, 2, 4, 5]
> >
> > So it is easy to iterate the layers and remove them in Order(1) time (per
> > removal).
> >
> > Alex
> >
> >
> > >
> > > On Wed, Apr 17, 2024 at 2:17 PM Alex Herbert >
> > > wrote:
> > >
> > > > Looks good to me.
> > > >
> > > > Any opinions on changing the LayerManager to keep the layers in a
> Deque
> > > > rather than a LinkedList. I think it would only require a change to
> the
> > > > following method:
> > > >
> > > > public final BloomFilter get(int depth)
> > > >
> > > > Performance will be the same as the Deque can be a LinkedList. This
> is
> > > more
> > > > about how any custom downstream code is currently using the
> collection
> > of
> > > > layers.
> > > >
> > > > Alex
> > >
> > >
> >
>
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
Re: [Collections-BloomFilter][Discuss] missing functionality?
The LayerdBloomFilter has a method find() that returns an array of ints
that are the indices into the layer array. This is easily reproducible
using an iterator.
There is also get() method that takes an integer argument (an index of the
bloom filter) and returns the Bloom filter from the layer. This is
reproducible but not as efficient using an iterator.
I think the array is the proper structure.
Claude
On Fri, Apr 19, 2024 at 11:06 AM Alex Herbert
wrote:
> On Fri, 19 Apr 2024 at 08:26, Claude Warren wrote:
>
> > While the Deque makes clear the idea of enqueueing and dequeueing the
> > layers it does not have the method to natively traverse and extract
> entries
> > from the middle of the queue. Nor would I expect it to. So I think the
> > Deque does not accurately reflect how the collection of Bloom filters is
> > utilized.
> >
>
> You can traverse and remove entries with the Iterator of the Deque:
>
> Deque d = new LinkedList<>();
> d.addAll(Arrays.asList(1, 2, 3, 4, 5));
> for (Iterator it = d.iterator(); it.hasNext();) {
> int i = it.next();
> if (i == 3) {
> it.remove();
> }
> }
> System.out.println(d);
>
> prints:
>
> [1, 2, 4, 5]
>
> So it is easy to iterate the layers and remove them in Order(1) time (per
> removal).
>
> Alex
>
>
> >
> > On Wed, Apr 17, 2024 at 2:17 PM Alex Herbert
> > wrote:
> >
> > > Looks good to me.
> > >
> > > Any opinions on changing the LayerManager to keep the layers in a Deque
> > > rather than a LinkedList. I think it would only require a change to the
> > > following method:
> > >
> > > public final BloomFilter get(int depth)
> > >
> > > Performance will be the same as the Deque can be a LinkedList. This is
> > more
> > > about how any custom downstream code is currently using the collection
> of
> > > layers.
> > >
> > > Alex
> >
> >
>
--
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: [VOTE] Release Apache Commons JCS 3.2.1 based on rc2
My vote. > Am 20.04.2024 um 12:25 schrieb Thomas Vandahl : > > Hi folks, > > We have fixed a few bugs since Apache Commons JCS 3.2 was released, so I > would like to release Apache Commons JCS 3.2.1. > > Apache Commons JCS 3.2.1 rc2 is available for review here: >https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2 (svn revision > 68673) > > [X] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE] Release Apache Commons JCS 3.2.1 based on rc2
Hi folks, We have fixed a few bugs since Apache Commons JCS 3.2 was released, so I would like to release Apache Commons JCS 3.2.1. Apache Commons JCS 3.2.1 rc2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2 (svn revision 68673) The Git tag commons-jcs3-3.2.1-rc2 commit for this RC is a2263c39fb07410ec75cf961362f9d9371298844 which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=a2263c39fb07410ec75cf961362f9d9371298844 You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch commons-jcs3-3.2.1-rc2 commons-jcs3-3.2.1-rc2 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1722/org/apache/commons/commons-jcs3/3.2.1/ These are the artifacts and their hashes: 20f898a3f7c41de29249d9e7e57cab754c5aa710da43c7018ce25413fa695d4edb363e036fd57884652e05ccf1e6b5946c7f4ff4b9a723affca42914e89935af commons-jcs3-dist-3.2.1-bin.tar.gz fe454deabd3311c2c7b59db7ce25db49f6ba0bccfd97bb9262e38adaeb00cbb16d6ba8542b75d816a5ca05098782cf44374d3fe0573814370923fef940d00c56 commons-jcs3-dist-3.2.1-bin.zip 7c9d912978f0f88a01e9e2a9475bd07a6c81379bb12f4a4cbdeec890899c7dbdcb6421c45c0655d28cf951f284ab32ca61d8a1aedbdad46d05bd127c060c5968 commons-jcs3-dist-3.2.1-src.tar.gz 4c513b03909fdfe9dff1e6d6689e33b8badd92f5d6d470172ad1fdfe86f0869398cc77ff2cb114db8648a332d47375c6615ac26d574fa9882b7564481cc14f72 commons-jcs3-dist-3.2.1-src.zip I have tested this with ***'mvn clean install site site:stage'*** using: -- Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Java version: 17.0.8, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home Default locale: de_DE, platform encoding: UTF-8 OS name: "mac os x", version: "11.7.10", arch: "x86_64", family: "mac" -- NOTE: Some JCS tests require a working multicast setup. If you get test failures from tests starting with UDPDiscovery*, make sure that your network supports multicast (most VPNs do not, for example). Details of changes since 3.2 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/index.html (note some *relative* links are broken and the 3.2.1 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 3.2): https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/commons-jcs3-core/japicmp.html RAT Report: https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc2/site/commons-jcs3-core/rat-report.html KEYS: https://www.apache.org/dist/commons/KEYS Please review the release candidate and vote. This vote will close no sooner than 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, tv, Release Manager (using key 88817402) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
