Re: [VOTE] Release Apache Commons RNG 1.6 based on RC2

2024-07-12 Thread Gary D. Gregory
+1

I tested the src zip file:
- SHA512 OK
- ASC OK
- Running 'mvn' (default goal) OK, BUT:

[INFO] --- javadoc:3.7.0:javadoc (default-cli) @ commons-rng-docs ---
[ERROR] Error fetching link: 
C:\Users\ggregory\rc\commons-rng-1.6-src\commons-rng-client-api\target\apidocs. 
Ignored it.
[ERROR] Error fetching link: 
C:\Users\ggregory\rc\commons-rng-1.6-src\commons-rng-core\target\apidocs. 
Ignored it.
[ERROR] Error fetching link: 
C:\Users\ggregory\rc\commons-rng-1.6-src\commons-rng-simple\target\apidocs. 
Ignored it.
[ERROR] Error fetching link: 
C:\Users\ggregory\rc\commons-rng-1.6-src\commons-rng-sampling\target\apidocs. 
Ignored it.
[INFO] No previous run data found, generating javadoc.

Using:

Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256)
Maven home: C:\java\apache-maven-3.9.8
Java version: 17.0.11, vendor: Eclipse Adoptium, runtime: C:\Program 
Files\Eclipse Adoptium\jdk-17.0.11.9-hotspot
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Gary

On 2024/07/09 12:21:56 Alex Herbert wrote:
> We have fixed a few bugs and added enhancements since Apache Commons RNG
> 1.5 was released, so I would like to release Apache Commons RNG 1.6.
> 
> Apache Commons RNG 1.6 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC2 (svn
> revision 70197)
> 
> The Git tag commons-rng-1.6-RC2 commit for this RC is commons-rng-1.6-RC2
> which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=commons-rng-1.6-RC2
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-rng.git --branch
> commons-rng-1.6-RC2 commons-rng-1.6-RC2
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1755/org/apache/commons/commons-rng/1.6/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Tue Jul 09 12:29:41 BST 2024
> commons-rng-1.6-bin.tar.gz=ede8acdf030d658d5ee2164185cb4e4e3b402f3b7032202d29016df76946f1355c0e968677fcae6eafcff3a8d6439c70e3514013c07fa34048c3f33e2005e7e4
> commons-rng-1.6-bin.zip=6011e1ea66226592168e6fb67d0c2740cf537edc0d4b549423e5ba7761084cb7222982fdf09ef9a6b8ea29c45e4a6cd09137d4d9ffd20172008f26a8a0804486
> commons-rng-1.6-src.tar.gz=8cb6e78b7a27aaf9492f549848465987838fd490a97996c5f7d516a648093db777d63544cd4be7550de22d69b80b070fdfa5e1f6dd143c2e75c70db684a39e2e
> commons-rng-1.6-src.zip=57e999f5f76155046cde915eaf33781f6361588a5e0d8776d4451149eca4d07fcf2b49612c5e6829181b75ad697e60f6243c0fedff0d932130315e44fe0a3237
> 
> Signatures may be validated on a system supporting a bash Unix shell by
> executing:
> svn co https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC2/
> cd 1.6-RC2
> chmod +x ./signature-validator.sh
> for m in client-api core simple sampling bom; do
> ./signature-validator.sh
> https://repository.apache.org/content/repositories/orgapachecommons-1755/org/apache/commons/commons-rng-${m}/1.6/;
> done
> 
> The source code contains examples that are not part of the public API.
> These examples contain Java 11 modules and are enabled using a profile (see
> below).
> 
> Note: Testing randomness using statistical thresholds results in failures
> at a given probability. The 'maven-surefire-plugin' is configured to re-run
> tests that fail, and pass the build if they succeed within the allotted
> number of reruns (the test will be marked as 'flaky' in the report).
> 
> I have tested this with 'mvn clean install' and 'mvn clean package site
> site:stage -Pcommons-rng-examples' using:
> 
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /Users/ah403/software/apache-maven-3
> Java version: 11.0.23, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "14.5", arch: "aarch64", family: "mac"
> 
> 
> Details of changes since 1.5 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC2/RELEASE-NOTES.txt
> 
> https://home.apache.org/~aherbert/commons-rng-1.6-RC2-site/changes-report.html
> 
> Site:
> https://home.apache.org/~aherbert/commons-rng-1.6-RC2-site/index.html
> (note some *relative* links are broken and the 1.6 directories are not
> yet created - these will be OK once the site is deployed.)
> 
> The site has been staged in a personal Apache space as it includes the
> examples modules documentation. These are not
> staged to the SVN dev staging area as these are not part of the official
> release artifacts.
> 
> JApiCmp Report (compared to 1.5):
> 
> https://home.apache.org/~aherbert/commons-rng-1.6-RC2-site/commons-rng-client-api/japicmp.html
> 
> https://home.apache.org/~aherbert/commons-rng-1.6-RC2-site/commons-rng-core/japicmp.html
> 
> https://home.apache.org/~aherbert/commons-rng-1.6-RC2-site/commons-rng-simple/japicmp.html
> 

Re: [VOTE] Release Apache Commons RNG 1.6 based on RC1

2024-07-08 Thread Gary D. Gregory
Oops, actually 'mvn clean install -DskipTests japicmp:cmp' fails with

[INFO] Reactor Summary for Apache Commons RNG 1.6:
[INFO]
[INFO] Apache Commons RNG . SUCCESS [ 21.207 s]
[INFO] Apache Commons RNG Client API .. SUCCESS [ 24.159 s]
[INFO] Apache Commons RNG Core  SUCCESS [ 25.444 s]
[INFO] Apache Commons RNG Simple .. SUCCESS [ 20.091 s]
[INFO] Apache Commons RNG Sampling  SUCCESS [ 42.508 s]
[INFO] Apache Commons RNG (Bill of Materials) . SUCCESS [  3.610 s]
[INFO] Apache Commons RNG Documentation ... FAILURE [  3.601 s]
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  02:22 min
[INFO] Finished at: 2024-07-08T13:42:52-04:00
[INFO] 
[ERROR] Failed to execute goal 
com.github.siom79.japicmp:japicmp-maven-plugin:0.21.2:cmp (default-cli) on 
project commons-rng-docs: The following artifacts could not be resolved: 
org.apache.commons:commons-rng-docs:jar:1.5 (absent): Could not find artifact 
org.apache.commons:commons-rng-docs:jar:1.5 in central 
(https://repo.maven.apache.org/maven2) -> [Help 1]

The POM for that module is probably missing some configuration.

Gary

On 2024/07/08 17:50:41 "Gary D. Gregory" wrote:
> Hello,
> 
> +1
> 
> This email contains this link that returns a 404 for
> 
> https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC1/site/changes-report.html
> 
> I see that for some reason, the site is in a personal folder instead of 
> https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC1/site, so I imagine 
> this is some search and replace error.
> 
> ASC OK.
> SHA512 OK.
> Running 'mvn' OK.
> Running 'mvn clean install -DskipTests japicmp:cmp' OK.
> 
> Using:
> 
> Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256)
> Maven home: C:\java\apache-maven-3.9.8
> Java version: 17.0.11, vendor: Eclipse Adoptium, runtime: C:\Program 
> Files\Eclipse Adoptium\jdk-17.0.11.9-hotspot
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Gary
> 
> On 2024/07/05 12:21:37 Alex Herbert wrote:
> > We have fixed a few bugs and added enhancements since Apache Commons RNG
> > 1.5 was released, so I would like to release Apache Commons RNG 1.6.
> > 
> > Apache Commons RNG 1.6 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC1 (svn
> > revision 70143)
> > 
> > The Git tag commons-rng-1.6-RC1 commit for this RC is commons-rng-1.6-RC1
> > which you can browse here:
> > 
> > https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=commons-rng-1.6-RC1
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-rng.git --branch
> > commons-rng-1.6-RC1 commons-rng-1.6-RC1
> > 
> > Maven artifacts are here:
> > 
> > https://repository.apache.org/content/repositories/orgapachecommons-/org/apache/commons/commons-rng/1.6/
> > 
> > These are the artifacts and their hashes:
> > 
> > #Release SHA-512s
> > #Fri Jul 05 12:42:04 BST 2024
> > commons-rng-1.6-bin.tar.gz=bd6475337043085fe48e0da4a10bbc06157b0a5cf0496e9784aedcdd27e60141575e127a49ae6dab21f2ec404e3f9b834c56155abfe58b0d8c7761f543bffdb8
> > commons-rng-1.6-bin.zip=dbbc2fe27c024302dfce1d62414aa3718a8bfcdfd639e6acfae5828f624ea4bbcd01511e16b429be6873e8952354eb542f90b6ff62f3a00a5e55af9a5d7480bf
> > commons-rng-1.6-src.tar.gz=6c1f89aaf3889296d830bcfd3f05ff650670ca3b8aa5b3c395b59801615f4b98e076f6731c6c7922adc348fa5f0367e1dec0bcb176318a589b61961b064666c1
> > commons-rng-1.6-src.zip=af96ba992540583e515a642a61ab03b98201f8f8e4b3ce7512f497feadf19aeea8b4fab2a8e113b7b65021744212f2b357a3907e2e1df74b4ea253875123d689
> > org.apache.commons_commons-rng-1.6.spdx.json=9742c043487e1e49fa2dd824370bef005148af757c0f8626188edf4d39deafe115e4caa10b015892e9d32c1fe1b911d4b4119cd33e59d5107900d8c1ad145112
> > 
> > Signatures may be validated on a system supporting a bash Unix shell by
> > executing:
> > svn co https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC1/
> > cd 1.6-RC1
> > chmod +x ./signature-validator.sh
> > for m in client-api core simple sampling bom; do
> > ./signature-validator.sh
> > https://repository.apache.org/content/repositories/orgapachecommons-1754/org/apache/commons/commons-rng-${m}/1.6/;
> > done
> > 
> > The sour

Re: [VOTE] Release Apache Commons RNG 1.6 based on RC1

2024-07-08 Thread Gary D. Gregory
Hello,

+1

This email contains this link that returns a 404 for

https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC1/site/changes-report.html

I see that for some reason, the site is in a personal folder instead of 
https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC1/site, so I imagine 
this is some search and replace error.

ASC OK.
SHA512 OK.
Running 'mvn' OK.
Running 'mvn clean install -DskipTests japicmp:cmp' OK.

Using:

Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256)
Maven home: C:\java\apache-maven-3.9.8
Java version: 17.0.11, vendor: Eclipse Adoptium, runtime: C:\Program 
Files\Eclipse Adoptium\jdk-17.0.11.9-hotspot
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Gary

On 2024/07/05 12:21:37 Alex Herbert wrote:
> We have fixed a few bugs and added enhancements since Apache Commons RNG
> 1.5 was released, so I would like to release Apache Commons RNG 1.6.
> 
> Apache Commons RNG 1.6 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC1 (svn
> revision 70143)
> 
> The Git tag commons-rng-1.6-RC1 commit for this RC is commons-rng-1.6-RC1
> which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=commons-rng-1.6-RC1
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-rng.git --branch
> commons-rng-1.6-RC1 commons-rng-1.6-RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-/org/apache/commons/commons-rng/1.6/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Fri Jul 05 12:42:04 BST 2024
> commons-rng-1.6-bin.tar.gz=bd6475337043085fe48e0da4a10bbc06157b0a5cf0496e9784aedcdd27e60141575e127a49ae6dab21f2ec404e3f9b834c56155abfe58b0d8c7761f543bffdb8
> commons-rng-1.6-bin.zip=dbbc2fe27c024302dfce1d62414aa3718a8bfcdfd639e6acfae5828f624ea4bbcd01511e16b429be6873e8952354eb542f90b6ff62f3a00a5e55af9a5d7480bf
> commons-rng-1.6-src.tar.gz=6c1f89aaf3889296d830bcfd3f05ff650670ca3b8aa5b3c395b59801615f4b98e076f6731c6c7922adc348fa5f0367e1dec0bcb176318a589b61961b064666c1
> commons-rng-1.6-src.zip=af96ba992540583e515a642a61ab03b98201f8f8e4b3ce7512f497feadf19aeea8b4fab2a8e113b7b65021744212f2b357a3907e2e1df74b4ea253875123d689
> org.apache.commons_commons-rng-1.6.spdx.json=9742c043487e1e49fa2dd824370bef005148af757c0f8626188edf4d39deafe115e4caa10b015892e9d32c1fe1b911d4b4119cd33e59d5107900d8c1ad145112
> 
> Signatures may be validated on a system supporting a bash Unix shell by
> executing:
> svn co https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC1/
> cd 1.6-RC1
> chmod +x ./signature-validator.sh
> for m in client-api core simple sampling bom; do
> ./signature-validator.sh
> https://repository.apache.org/content/repositories/orgapachecommons-1754/org/apache/commons/commons-rng-${m}/1.6/;
> done
> 
> The source code contains examples that are not part of the public API.
> These examples contain Java 11 modules and are enabled using a profile (see
> below).
> 
> Note: Testing randomness using statistical thresholds results in failures
> at a given probability. The 'maven-surefire-plugin' is configured to re-run
> tests that fail, and pass the build if they succeed within the allotted
> number of reruns (the test will be marked as 'flaky' in the report).
> 
> I have tested this with 'mvn clean install' and 'mvn clean package site
> site:stage -Pcommons-rng-examples' using:
> 
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /Users/ah403/software/apache-maven-3
> Java version: 11.0.23, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "14.5", arch: "aarch64", family: "mac"
> 
> Details of changes since 1.5 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC1/site/changes-report.html
> 
> Site:
> https://home.apache.org/~aherbert/commons-rng-1.6-RC1-site/index.html
> (note some *relative* links are broken and the 1.6 directories are not
> yet created - these will be OK once the site is deployed.)
> 
> JApiCmp Report (compared to 1.5):
> 
> https://home.apache.org/~aherbert/commons-rng-1.6-RC1-site/commons-rng-client-api/japicmp.html
> 
> https://home.apache.org/~aherbert/commons-rng-1.6-RC1-site/commons-rng-core/japicmp.html
> 
> https://home.apache.org/~aherbert/commons-rng-1.6-RC1-site/commons-rng-simple/japicmp.html
> 
> https://home.apache.org/~aherbert/commons-rng-1.6-RC1-site/commons-rng-sampling/japicmp.html
> 
> RevApi Report (compared to 1.5):
> 
> https://home.apache.org/~aherbert/commons-rng-1.6-RC1-site/commons-rng-client-api/revapi-report.html
> 
> 

Re: [VOTE] Release Apache Commons Email Parent POM 2.0.0-M1 based on RC1

2024-06-18 Thread Gary D. Gregory
My +1

Gary

On 2024/06/15 17:19:50 Gary Gregory wrote:
> We have fixed a few bugs and added enhancements since Apache Commons
> Email Parent POM 1.6.0 was released, so I would like to release Apache
> Commons Email Parent POM 2.0.0-M1.
> 
> The reason for a major new release is to deal with the horror show of
> Javax vs.Jakarta namespaces.
> 
> Apache Commons Email Parent POM 2.0.0-M1 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/email/2.0.0-M1-RC1
> (svn revision 69780)
> 
> The Git tag commons-email-2.0.0-M1-RC1 commit for this RC is
> a514720114343be667e886123eddc90b36e72038 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-email.git;a=commit;h=a514720114343be667e886123eddc90b36e72038
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-email.git
> --branch commons-email-2.0.0-M1-RC1 commons-email-2.0.0-M1-RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1749/org/apache/commons/commons-email2-parent/2.0.0-M1/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> source/commons-email2-2.0.0-M1-src.tar.gz=9f2250cd484079e0d08cac0982985aae5261b87c42a36a4eaf61d6948e5afe0e43310819d6f442a864d95643b613dc2f197e455ab485afe794d614391145737d
> source/commons-email2-2.0.0-M1-src.zip=d9c8f206e0fd3e5b1fb38ea67d2e8f15eec53e340a64d4db0b253bfdf7edbad70710eb1ae6b0227b8926c072dc12e9772f1dbc9539217df8bb458318f700ab15
> binaries/commons-email2-2.0.0-M1-bin.tar.gz=c3ee2d6e0346f8bb15b9890767cd990353814cfacf18b8437f66fa573d63031f8ff47ce1d8de2868d5fa2ab4d04694e3aa1d8bd73faec5f3dea461c109ac8320
> binaries/commons-email2-2.0.0-M1-bin.zip=ba1207159f5c833bde93c691185da4114c040978b4454cab164582a3b633d86a49ebd91167c1786d7337d9faae982823ad5d4c24467abda9ca3331c3d24c1027
> 
> I have tested this with 'mvn' (default goal) using:
> 
> 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.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
> Maven home: /usr/local/Cellar/maven/3.9.7/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.5", arch: "x86_64", family: "mac"
> 
> Darwin  23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:09:52
> PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64
> 
> Details of changes since 1.6.0 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/email/2.0.0-M1-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/email/2.0.0-M1-RC1/site/changes-report.html
> 
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/email/2.0.0-M1-RC1/site/index.html
> (note some *relative* links are broken and the 2.0.0-M1
> directories are not yet created - these will be OK once the site is
> deployed.)
> There is no JApiCmp report in this major release.,
> 
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/email/2.0.0-M1-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-email.git
> --branch commons-email-2.0.0-M1-RC1 commons-email-2.0.0-M1-RC1
> cd commons-email-2.0.0-M1-RC1
> 
> 1b) Download and unpack the source archive from:
> 
> https://dist.apache.org/repos/dist/dev/commons/email/2.0.0-M1-RC1/source
> 
> 2) Check Apache licenses
> 
> This step is not required if the site includes a RAT report page which
> you then must check.
> 
> mvn apache-rat:check
> 
> 3) Check binary compatibility
> 
> Older components still use Apache Clirr:
> 
> This step is not required if the site includes a Clirr report page
> which you then must check.
> 
> mvn clirr:check
> 
> Newer components use JApiCmp with the japicmp Maven Profile:
> 
> This step is not required if the site includes a JApiCmp report page
> which you then must check.
> 
> mvn install -DskipTests -P japicmp japicmp:cmp
> 
> 4) Build the package
> 
> mvn -V clean package
> 
> You can record the Maven and Java version produced by -V in your VOTE 

Re: [IO] IO-855 PeekableInputStream?

2024-06-18 Thread Gary D. Gregory
PING!

On 2024/04/29 12:27:10 Gary Gregory wrote:
> RE https://issues.apache.org/jira/browse/IO-855
> 
> There are zero tests or usage in IO for PeekableInputStream.
> 
> Could the original author add some?
> 
> Why does PeekableInputStream extend CircularBufferInputStream instead
> of BufferedInputStream?
> 
> TY!
> Gary
> 
> -
> 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] 4.5.0-M2 is next to capture latest bloom filter code

2024-06-16 Thread Gary D. Gregory
The RC is available :)

On 2024/06/13 14:04:47 Gary Gregory wrote:
> That all sounds good to me. I'll cut a release over the next few days.
> 
> Gary
> 
> On Thu, Jun 13, 2024, 9:48 AM Claude Warren  wrote:
> 
> > Given the hectic nature of my life at the moment, I would say longer than a
> > week.
> > Would it make sense to do an M2 to verify the APIs and then lock down and
> > comb through documentation with a fine tooth comb, looking for errors and
> > missing explanations before an M3 that has no code, just documentation
> > changes?
> >
> > Claude
> >
> > On Thu, Jun 13, 2024 at 12:47 PM Gary Gregory 
> > wrote:
> >
> > > It would be better IMO to have the updated documentation for M2 but not
> > > critical, let me know if you think you can do it "soon" (say within a
> > week)
> > > or if it's just on a longer term to-do list.
> > >
> > > TY,
> > > Gary
> > >
> > > On Thu, Jun 13, 2024, 3:39 AM Claude Warren  wrote:
> > >
> > > > The only changes I am considering are to remove any stream usage within
> > > the
> > > > code, no external changes.  Additionally, there may be some new
> > > > documentation coming but that can wait until after M2.
> > > >
> > > > Thanks for all your hard work on this.
> > > > Claude
> > > >
> > > > On Wed, Jun 12, 2024 at 7:30 PM Gary D. Gregory 
> > > > wrote:
> > > >
> > > > > HI All, Claude W, Alex H:
> > > > >
> > > > > I would like to cut a 4.5.0-M2 RC later this week to capture latest
> > > bloom
> > > > > filter code.
> > > > >
> > > > > Feel free to ask me to hold back if you plan further changes first.
> > > > >
> > > > > TY!
> > > > > Gary
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > >
> > > > >
> > > >
> > > > --
> > > > LinkedIn: http://www.linkedin.com/in/claudewarren
> > > >
> > >
> >
> >
> > --
> > LinkedIn: http://www.linkedin.com/in/claudewarren
> >
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [LANG] Add Any Checks for Not Checks in StringUtils

2024-06-13 Thread Gary D. Gregory
On 2024/06/13 00:22:13 Department 8 wrote:
> I see the point you are making. Thanks for taking the time to review it.

And thank you for engaging with us on improving this component! :-)

Gary

> 
> On Wed, Jun 12, 2024, 23:30 Gary Gregory  wrote:
> 
> > See also my comment in the PR.
> >
> > Gary
> >
> > On Wed, Jun 12, 2024, 1:22 PM Department 8 
> > wrote:
> >
> > > Haha! It was in fact because of other methods that have simple negation
> > > that I thought maybe giving a PR would be Okay :)
> > >
> > > I think that many times, it is the Boolean Logic that may trivial for us,
> > > but for some who may be using them to have a utility methods like
> > > isNotBlank aka (!isBlank) maybe helpful and would de-clutter the client
> > > code to a good extent. So it is more of a clean fix for them.
> > >
> > > Another way may be to - do a for loop on all of them and once you find
> > > NotBlank to be true you return true, else iterate till end and return
> > false
> > > (the actual negated logic of isAllBlank) but that would mean for the
> > > clients of the API to write that helper function for themselves. So this
> > > can provide an easy wrap.
> > >
> > > On Wed, 12 Jun 2024 at 22:43, Alex Herbert 
> > > wrote:
> > >
> > > > On Wed, 12 Jun 2024 at 18:03, Department 8 
> > > > wrote:
> > > >
> > > > > Sorry Alex just now saw your email, before sending out the PR!
> > > > >
> > > > > I had done just for isAllEmpty and isAllBlank.
> > > > >
> > > > > Can you tell me more on what can be done, when you said the
> > following:
> > > > >
> > > > > If you are simply negating the result of another method then this use
> > > > case
> > > > > may be better served with addition of a suitable example to the
> > javadoc
> > > > of
> > > > > the method you are negating.
> > > > >
> > > > > Like do you want me to add examples of use-cases?
> > > > >
> > > >
> > > > I've seen the PR. The new methods are a simple boolean negation of
> > > existing
> > > > methods. So these are not adding functionality that cannot be achieved
> > > with
> > > > the current API.
> > > >
> > > > Note that a quick check in StringUtils for 'return !' finds these
> > > methods:
> > > >
> > > > public static boolean isNoneBlank(final CharSequence... css) {
> > > >   return !isAnyBlank(css);
> > > > }
> > > >
> > > > public static boolean isNoneEmpty(final CharSequence... css) {
> > > >   return !isAnyEmpty(css);
> > > > }
> > > >
> > > > There are two others for single CharSequence args as well: isNotBlank
> > and
> > > > isNotEmpty.
> > > >
> > > > So it is not without precedent to add more methods that are simple
> > > > negations. However we have to consider if this is code bloat, or if the
> > > > addition of simple negation methods is so useful that it warrants
> > > > inclusion. I would currently consider this as redundant given the lack
> > of
> > > > actual logic in the methods.
> > > >
> > > > Alex
> > > >
> > > >
> > > > >
> > > > > On Wed, 12 Jun 2024 at 22:29, Department 8  > >
> > > > > wrote:
> > > > >
> > > > > > I just realized the subject name is bad. But here are the two small
> > > > > > methods I propose - *isAnyNotBlank* and *isAnyNotEmpty*.
> > > > > >
> > > > > > Please find the pull request as here:
> > > > > > https://github.com/apache/commons-lang/pull/1234
> > > > > >
> > > > > > On Wed, 12 Jun 2024 at 21:52, Department 8 <
> > manstein.fe...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Hey!
> > > > > >>
> > > > > >> Recently when using StringUtils in one of our projects I had felt
> > > the
> > > > > >> urgent need to have a utility method like => isAnyNotBlank.
> > > > > >>
> > > > > >> I was able to achieve this using the negation of isAllBlank, so I
> > am
> > > > > >> thinking of introducing the code with all tests.
> > > > > >>
> > > > > >> It is ready to be pushed to PR. Do let me know what you think and
> > > what
> > > > > >> are the next steps for the same?
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [DRAFT] June Report to the Board

2024-06-13 Thread Gary D. Gregory
On 2024/06/12 22:25:29 sebb wrote:
> On Wed, 12 Jun 2024 at 18:58, Gary D. Gregory  wrote:
> >
> > On 2024/06/12 17:17:24 Phil Steitz wrote:
> 
> > > +1
> > > I have had to filter out most of the messages and once I do that, there is
> > > almost no actual discussion on-list.  I am worried that when people do try
> > > to start discussion, the messages are being missed.  I personally see the
> > > lack of ml discussion as a problem.  Lots of code changes are happening
> > > with no discussion, other than maybe random nits on PRs ending up in 
> > > github
> > > threads that don't end up organized that well in list archives.  This
> > > problem is not unique to Commons.
> >
> > Hi Phil,
> >
> > We had a discussion a while back about creating a "bot" email list but:
> > - no one actually proposed anything concrete and did any work
> 
> That's not strictly true.
> There were various suggestions (e.g. run dependabot less frequently,

We run it once a week which feels to me like the sweet spot. We _used to_, like 
Log4j does, run it once a day.

> or only on demand) 

The would defeats one of the purposes of the "bot" part of Dependabot.

but they were shouted down, so no action was taken
> as it would have been vetoed.
> 
> > - we already have bot lists like "commit", "notifications", "issues", can't 
> > we reuse those?
> 
> That is part of the problem: the commits list is overrun with
> dependabot commits.

I don't know what you are proposing here, a new list called "gitbot"?

Gary

> 
> > - I don't know if GitHub lets us configure target emails for "I created a 
> > PR" (or someone commented on a PR), vs. other types of messages.
> 
> > Gary
> >
> > >
> > > Phil
> > >
> > > >
> > > >
> > > > > Most if not all of our increasing contributions are coming in
> > > > > through GitHub pull requests. This is working well for us: GitHub PRs
> > > > with
> > > > > continuous integration builds providing great infrastructure and
> > > > validation of
> > > > > PRs and the existing code base. The flip side is that the increase in
> > > > GitHub
> > > > > usage is matched by a decrease in Jira usage.
> > > > >
> > > > > Gary
> > > > >
> > > > > -
> > > > > 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
> >
> 
> -
> 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: [DRAFT] June Report to the Board

2024-06-12 Thread Gary D. Gregory
On 2024/06/12 17:17:24 Phil Steitz wrote:
> On Wed, Jun 12, 2024 at 7:27 AM sebb  wrote:
> 
> > On Wed, 12 Jun 2024 at 14:45, Gary D. Gregory  wrote:
> > >
> > > Hello All,
> > >
> > > Here is the draft of our board report for June I plan on submitting in a
> > day or so, feedback is welcome.
> > >
> > > ## Description:
> > > The mission of Apache Commons is the creation and maintenance of Java
> > focused
> > > reusable libraries and components
> > >
> > > ## Project Status:
> > > Current project status: Ongoing with moderate activity.
> > > Issues for the board: none.
> > >
> > > ## Membership Data:
> > > Apache Commons was founded 2007-06-19 (17 years ago)
> > > There are currently 149 committers and 44 PMC members in this project.
> > > The Committer-to-PMC ratio is roughly 5:2.
> >
> > Missing from this paragraph is the fact that Commons has enabled
> > universal commit.
> >
> > > Community changes, past quarter:
> > > - Claude Warren was added to the PMC on 2024-03-22
> > > - No new committers. Last addition was Claude Warren on 2022-02-01.
> > >
> > > ## Project Activity:
> > > Many releases of our components:
> > > CONFIGUATION-2.11.0 was released on 2024-06-10.
> >
> > Is that a new component?
> >
> > > NET-3.11.1 was released on 2024-06-10.
> > > PARENT-71 was released on 2024-06-10.
> > > JEXL-3.4.0 was released on 2024-06-06.
> > > NET-3.11.0 was released on 2024-05-31.
> > > VALIDATOR-1.9.0 was released on 2024-05-28.
> > > JCS-3.2.1 was released on 2024-05-27.
> > > DAEMON-1.4.0 was released on 2024-05-24.
> > > CLI-1.8.0 was released on 2024-05-23.
> > > COMPRESS-1.26.2 was released on 2024-05-23.
> > > LOGGING-1.3.2 was released on 2024-05-15.
> > > PARENT-70 was released on 2024-05-15.
> > > CSV-1.11.0 was released on 2024-05-02.
> > > RELEASE-PLUGIN-1.8.2 was released on 2024-04-19.
> > > CLI-1.7.0 was released on 2024-04-18.
> > > IMAGING-1.0.0-alpha5 was released on 2024-04-18.
> > > TEXT-1.12.0 was released on 2024-04-16.
> > > BUILD-PLUGIN-1.14.0 was released on 2024-04-15.
> > > IO-2.16.1 was released on 2024-04-08.
> > > COLLECTIONS-4.5.0-M1 was released on 2024-04-02.
> > > IMAGING-1.0.0-alpha4 was released on 2024-04-02.
> > > PARENT-69 was released on 2024-04-01.
> > > IO-2.16.0 was released on 2024-03-28.
> > > LOGGING-1.3.1 was released on 2024-03-24.
> > > PARENT-68 was released on 2024-03-23.
> > > CONFIGURATION-2.10.1 was released on 2024-03-20.
> > > CONFIGURATION-2.10.0 was released on 2024-03-13.
> >
> > The above list should probably be sorted
> >
> > > ## Community Health:
> > > We welcomed Claude Warren as our latest PMC member. Mailing list
> > activity has
> > > increased.
> >
> > Much of the increased mailing list activity is driven by dependabot
> > PRs, many of which are useless, as it does not take Java compatibility
> > into account.
> >
> 
> +1
> I have had to filter out most of the messages and once I do that, there is
> almost no actual discussion on-list.  I am worried that when people do try
> to start discussion, the messages are being missed.  I personally see the
> lack of ml discussion as a problem.  Lots of code changes are happening
> with no discussion, other than maybe random nits on PRs ending up in github
> threads that don't end up organized that well in list archives.  This
> problem is not unique to Commons.

Hi Phil,

We had a discussion a while back about creating a "bot" email list but:
- no one actually proposed anything concrete and did any work
- we already have bot lists like "commit", "notifications", "issues", can't we 
reuse those?
- I don't know if GitHub lets us configure target emails for "I created a PR" 
(or someone commented on a PR), vs. other types of messages.

Gary

> 
> Phil
> 
> >
> >
> > > Most if not all of our increasing contributions are coming in
> > > through GitHub pull requests. This is working well for us: GitHub PRs
> > with
> > > continuous integration builds providing great infrastructure and
> > validation of
> > > PRs and the existing code base. The flip side is that the increase in
> > GitHub
> > > usage is matched by a decrease in Jira usage.
> > >
> > > Gary
> > >
> > > -
> > > 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: [DRAFT] June Report to the Board

2024-06-12 Thread Gary D. Gregory
On 2024/06/12 14:26:53 sebb wrote:
> On Wed, 12 Jun 2024 at 14:45, Gary D. Gregory  wrote:
> >
> > Hello All,
> >
> > Here is the draft of our board report for June I plan on submitting in a 
> > day or so, feedback is welcome.
> >
> > ## Description:
> > The mission of Apache Commons is the creation and maintenance of Java 
> > focused
> > reusable libraries and components
> >
> > ## Project Status:
> > Current project status: Ongoing with moderate activity.
> > Issues for the board: none.
> >
> > ## Membership Data:
> > Apache Commons was founded 2007-06-19 (17 years ago)
> > There are currently 149 committers and 44 PMC members in this project.
> > The Committer-to-PMC ratio is roughly 5:2.
> 
> Missing from this paragraph is the fact that Commons has enabled
> universal commit.
> 
> > Community changes, past quarter:
> > - Claude Warren was added to the PMC on 2024-03-22
> > - No new committers. Last addition was Claude Warren on 2022-02-01.
> >
> > ## Project Activity:
> > Many releases of our components:
> > CONFIGUATION-2.11.0 was released on 2024-06-10.
> 
> Is that a new component?

Edited for typo.

> 
> > NET-3.11.1 was released on 2024-06-10.
> > PARENT-71 was released on 2024-06-10.
> > JEXL-3.4.0 was released on 2024-06-06.
> > NET-3.11.0 was released on 2024-05-31.
> > VALIDATOR-1.9.0 was released on 2024-05-28.
> > JCS-3.2.1 was released on 2024-05-27.
> > DAEMON-1.4.0 was released on 2024-05-24.
> > CLI-1.8.0 was released on 2024-05-23.
> > COMPRESS-1.26.2 was released on 2024-05-23.
> > LOGGING-1.3.2 was released on 2024-05-15.
> > PARENT-70 was released on 2024-05-15.
> > CSV-1.11.0 was released on 2024-05-02.
> > RELEASE-PLUGIN-1.8.2 was released on 2024-04-19.
> > CLI-1.7.0 was released on 2024-04-18.
> > IMAGING-1.0.0-alpha5 was released on 2024-04-18.
> > TEXT-1.12.0 was released on 2024-04-16.
> > BUILD-PLUGIN-1.14.0 was released on 2024-04-15.
> > IO-2.16.1 was released on 2024-04-08.
> > COLLECTIONS-4.5.0-M1 was released on 2024-04-02.
> > IMAGING-1.0.0-alpha4 was released on 2024-04-02.
> > PARENT-69 was released on 2024-04-01.
> > IO-2.16.0 was released on 2024-03-28.
> > LOGGING-1.3.1 was released on 2024-03-24.
> > PARENT-68 was released on 2024-03-23.
> > CONFIGURATION-2.10.1 was released on 2024-03-20.
> > CONFIGURATION-2.10.0 was released on 2024-03-13.
> 
> The above list should probably be sorted

It is sorted, in chronological release older as it always has been.

It could be sorted in AB order...

Gary

> 
> > ## Community Health:
> > We welcomed Claude Warren as our latest PMC member. Mailing list activity 
> > has
> > increased.
> 
> Much of the increased mailing list activity is driven by dependabot
> PRs, many of which are useless, as it does not take Java compatibility
> into account.
> 
> 
> > Most if not all of our increasing contributions are coming in
> > through GitHub pull requests. This is working well for us: GitHub PRs with
> > continuous integration builds providing great infrastructure and validation 
> > of
> > PRs and the existing code base. The flip side is that the increase in GitHub
> > usage is matched by a decrease in Jira usage.
> >
> > Gary
> >
> > -
> > 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: [DRAFT] June Report to the Board

2024-06-12 Thread Gary D. Gregory
I've edited the sections commented on as:

## Project Activity:
Many releases of our components:
CONFIGURATION-2.11.0 was released on 2024-06-10.
NET-3.11.1 was released on 2024-06-10.
PARENT-71 was released on 2024-06-10.
JEXL-3.4.0 was released on 2024-06-06.
NET-3.11.0 was released on 2024-05-31.
VALIDATOR-1.9.0 was released on 2024-05-28.
JCS-3.2.1 was released on 2024-05-27.
DAEMON-1.4.0 was released on 2024-05-24.
CLI-1.8.0 was released on 2024-05-23.
COMPRESS-1.26.2 was released on 2024-05-23.
LOGGING-1.3.2 was released on 2024-05-15.
PARENT-70 was released on 2024-05-15.
CSV-1.11.0 was released on 2024-05-02.
RELEASE-PLUGIN-1.8.2 was released on 2024-04-19.
CLI-1.7.0 was released on 2024-04-18.
IMAGING-1.0.0-alpha5 was released on 2024-04-18.
TEXT-1.12.0 was released on 2024-04-16.
BUILD-PLUGIN-1.14.0 was released on 2024-04-15.
IO-2.16.1 was released on 2024-04-08.
COLLECTIONS-4.5.0-M1 was released on 2024-04-02.
IMAGING-1.0.0-alpha4 was released on 2024-04-02.
PARENT-69 was released on 2024-04-01.
IO-2.16.0 was released on 2024-03-28.
LOGGING-1.3.1 was released on 2024-03-24.
PARENT-68 was released on 2024-03-23.
CONFIGURATION-2.10.1 was released on 2024-03-20.
CONFIGURATION-2.10.0 was released on 2024-03-13.

## Community Health:
We welcomed Claude Warren as our latest PMC member. Mailing list activity has
increased mostly due to GitHub automated emails. Most if not all of our growth
in contributions are coming in through GitHub pull requests. GitHub PRs with
our use of GitHub continuous integration builds provide
validation of PRs and the existing code base. The flip side is that the
increase in GitHub usage is matched by a decrease in Jira usage.

Gary

On 2024/06/12 14:17:50 Gilles Sadowski wrote:
> Hi.
> 
> Le mer. 12 juin 2024 à 15:45, Gary D. Gregory  a écrit :
> >
> > Hello All,
> >
> > Here is the draft of our board report for June I plan on submitting in a 
> > day or so, feedback is welcome.
> >
> > ## Description:
> > The mission of Apache Commons is the creation and maintenance of Java 
> > focused
> > reusable libraries and components
> >
> > ## Project Status:
> > Current project status: Ongoing with moderate activity.
> > Issues for the board: none.
> >
> > ## Membership Data:
> > Apache Commons was founded 2007-06-19 (17 years ago)
> > There are currently 149 committers and 44 PMC members in this project.
> > The Committer-to-PMC ratio is roughly 5:2.
> >
> > Community changes, past quarter:
> > - Claude Warren was added to the PMC on 2024-03-22
> > - No new committers. Last addition was Claude Warren on 2022-02-01.
> >
> > ## Project Activity:
> > Many releases of our components:
> > CONFIGUATION-2.11.0 was released on 2024-06-10.
> > NET-3.11.1 was released on 2024-06-10.
> > PARENT-71 was released on 2024-06-10.
> > JEXL-3.4.0 was released on 2024-06-06.
> > NET-3.11.0 was released on 2024-05-31.
> > VALIDATOR-1.9.0 was released on 2024-05-28.
> > JCS-3.2.1 was released on 2024-05-27.
> > DAEMON-1.4.0 was released on 2024-05-24.
> > CLI-1.8.0 was released on 2024-05-23.
> > COMPRESS-1.26.2 was released on 2024-05-23.
> > LOGGING-1.3.2 was released on 2024-05-15.
> > PARENT-70 was released on 2024-05-15.
> > CSV-1.11.0 was released on 2024-05-02.
> > RELEASE-PLUGIN-1.8.2 was released on 2024-04-19.
> > CLI-1.7.0 was released on 2024-04-18.
> > IMAGING-1.0.0-alpha5 was released on 2024-04-18.
> > TEXT-1.12.0 was released on 2024-04-16.
> > BUILD-PLUGIN-1.14.0 was released on 2024-04-15.
> > IO-2.16.1 was released on 2024-04-08.
> > COLLECTIONS-4.5.0-M1 was released on 2024-04-02.
> > IMAGING-1.0.0-alpha4 was released on 2024-04-02.
> > PARENT-69 was released on 2024-04-01.
> > IO-2.16.0 was released on 2024-03-28.
> > LOGGING-1.3.1 was released on 2024-03-24.
> > PARENT-68 was released on 2024-03-23.
> > CONFIGURATION-2.10.1 was released on 2024-03-20.
> > CONFIGURATION-2.10.0 was released on 2024-03-13.
> >
> > ## Community Health:
> > We welcomed Claude Warren as our latest PMC member. Mailing list activity 
> > has
> > increased. Most if not all of our increasing contributions are coming in
> > through GitHub pull requests. This is working well for us:
> 
> It is just one opinion, which I (still) do not share.
> [Not denying the many utilities readily available from GH; the
> issues lay elsewhere...]
> 
> 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



[COLLECTIONS] 4.5.0-M2 is next to capture latest bloom filter code

2024-06-12 Thread Gary D. Gregory
HI All, Claude W, Alex H:

I would like to cut a 4.5.0-M2 RC later this week to capture latest bloom 
filter code.

Feel free to ask me to hold back if you plan further changes first.

TY!
Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



[DRAFT] June Report to the Board

2024-06-12 Thread Gary D. Gregory
Hello All,

Here is the draft of our board report for June I plan on submitting in a day or 
so, feedback is welcome.

## Description:
The mission of Apache Commons is the creation and maintenance of Java focused 
reusable libraries and components

## Project Status:
Current project status: Ongoing with moderate activity.
Issues for the board: none.

## Membership Data:
Apache Commons was founded 2007-06-19 (17 years ago)
There are currently 149 committers and 44 PMC members in this project.
The Committer-to-PMC ratio is roughly 5:2.

Community changes, past quarter:
- Claude Warren was added to the PMC on 2024-03-22
- No new committers. Last addition was Claude Warren on 2022-02-01.

## Project Activity:
Many releases of our components:
CONFIGUATION-2.11.0 was released on 2024-06-10.
NET-3.11.1 was released on 2024-06-10.
PARENT-71 was released on 2024-06-10.
JEXL-3.4.0 was released on 2024-06-06.
NET-3.11.0 was released on 2024-05-31.
VALIDATOR-1.9.0 was released on 2024-05-28.
JCS-3.2.1 was released on 2024-05-27.
DAEMON-1.4.0 was released on 2024-05-24.
CLI-1.8.0 was released on 2024-05-23.
COMPRESS-1.26.2 was released on 2024-05-23.
LOGGING-1.3.2 was released on 2024-05-15.
PARENT-70 was released on 2024-05-15.
CSV-1.11.0 was released on 2024-05-02.
RELEASE-PLUGIN-1.8.2 was released on 2024-04-19.
CLI-1.7.0 was released on 2024-04-18.
IMAGING-1.0.0-alpha5 was released on 2024-04-18.
TEXT-1.12.0 was released on 2024-04-16.
BUILD-PLUGIN-1.14.0 was released on 2024-04-15.
IO-2.16.1 was released on 2024-04-08.
COLLECTIONS-4.5.0-M1 was released on 2024-04-02.
IMAGING-1.0.0-alpha4 was released on 2024-04-02.
PARENT-69 was released on 2024-04-01.
IO-2.16.0 was released on 2024-03-28.
LOGGING-1.3.1 was released on 2024-03-24.
PARENT-68 was released on 2024-03-23.
CONFIGURATION-2.10.1 was released on 2024-03-20.
CONFIGURATION-2.10.0 was released on 2024-03-13.

## Community Health:
We welcomed Claude Warren as our latest PMC member. Mailing list activity has
increased. Most if not all of our increasing contributions are coming in
through GitHub pull requests. This is working well for us: GitHub PRs with
continuous integration builds providing great infrastructure and validation of
PRs and the existing code base. The flip side is that the increase in GitHub
usage is matched by a decrease in Jira usage.

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [VOTE] Release Apache Commons Net 3.11.1 based on RC1

2024-06-09 Thread Gary D. Gregory
Hi Phil,

I think those are OK, and likely old (or new but more on this later): The 
default goal in this POM (clean apache-rat:check javadoc:javadoc 
checkstyle:check verify japicmp:cmp) does not run SpotBugs or PMD; but the 
SpotBugs report is still generated. This means GH CI and and default builds 
don't fail for SpotBugs.

Cleaning up SpotBugs and PMD issue is on my long term to-do list, then SpotBugs 
and PMD checks can be added to the default goal.

It's likely that as SpotBugs versions have been bumped new types of issues are 
detected.

HTH,
Gary

On 2024/06/10 00:46:46 Phil Steitz wrote:
> There are a bunch of findbugs errors reported.  Is this expected?
> 
> Phil
> 
> On Fri, Jun 7, 2024 at 5:40 AM Gary Gregory  wrote:
> 
> > We have fixed a few bugs and added enhancements since Apache Commons
> > Net 3.11.0 was released, so I would like to release Apache Commons Net
> > 3.11.1.
> >
> > Apache Commons Net 3.11.1 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/net/3.11.1-RC1 (svn
> > revision 69595)
> >
> > The Git tag commons-net-3.11.1-RC1 commit for this RC is
> > 0505563df6664a8c5b5fad6897cd373aba809c64 which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-net.git;a=commit;h=0505563df6664a8c5b5fad6897cd373aba809c64
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-net.git
> > --branch 
> > commons-net-3.11.1-RC1 commons-net-3.11.1-RC1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1738/commons-net/commons-net/3.11.1/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Fri Jun 07 12:26:06 UTC 2024
> >
> > commons-net-3.11.1-bin.tar.gz=90c1e62d8fe1d8c26588fbfefeb41f6ef16a349b8851e75297363c7d2eca5cb27d313a11e2f532f9b9c8b2790f1b9636f39c5fd563a6e9403ac6363415245bd9
> >
> > commons-net-3.11.1-bin.zip=e2e378d247ab4a1260d01c18579abe247bcca05246b9340edfb07f7bf5aa216ea745f590696bda9d43806b273ef8f8e73ed7a60b4f47f77dab45a5f657467fba
> >
> > commons-net-3.11.1-bom.json=f954bd7d2560a423b2c93f78d92cc6b658c5fab66465bc0adb3e455385448f8b32f0319c229703645a8ad9cae88dccb689e6783e85d4f450671d7563a485ac3d
> >
> > commons-net-3.11.1-bom.xml=0937d4448e3c52987ab3ba9268ebe68ab85e748a394d1c75efa6682dd265bd159c7f6c8e0bbb10fa61f2f13675ebb8d7753b2fefadee96be1e4c9da391bf9aff
> >
> > commons-net-3.11.1-javadoc.jar=fe46639c1df071ec1e4f785ff4c2b55f8b0604a3d90b9395852f9be4a4b57a9e490ab985a79fc29a6e287944a2cfc2352837685eb01795f5647ec5c95b6cbd43
> >
> > commons-net-3.11.1-sources.jar=9aa64b66154ee1775d9af6b8d99e9cb771c5234545df716e2273eb9a050cd683dda3d8520b660207f23229ccaf08533f6339ebfbb75210d0ff43df41d7419e33
> >
> > commons-net-3.11.1-src.tar.gz=0999067cc73cb0e0ab4940302180a0afa998b37c51f93c1c744bf1d346d14c89283166a665283d98200e98f0b8c39854f17493890d49ddad5769c4deb49de37e
> >
> > commons-net-3.11.1-src.zip=6820a334da2b4144acbd73e8f254bcd39cf46d83ecd4974d11e97c84fb573d78132546ac05530b3a88f7db3e59a3660600f3436716cd76c44016c797302ec8a9
> >
> > commons-net-3.11.1-test-sources.jar=0697dfe901f6f2f307c3ea813c22181c90b0b762549cc8a9e3e0394dadb2b5868e46b307630608a34df973ca5d6e346eb36823ae2a58d8d62d20ad47be3463dd
> >
> > commons-net-3.11.1-tests.jar=be5614c73ca8fe1f78ce58cc735ee34a32698ec956407562383b8257eb19a8211c0ca448507f4bfaf1bb85bbc6b3bb189edbbbfb71b5d92b5e113af579c74810
> >
> > commons-net-examples-3.11.1.jar=160512e72ae002e4214a23d0d20694295b8265a19a7889183e130d0b9e17f4a5edb22b12d3492e505269e3427935ff17d0f3f29557dd09103b68473df4648566
> >
> > commons-net-ftp-3.11.1.jar=1fc341b3ef5759858b355495d1d07fe8fdc4f6773d4619db6b67f86c39e60e7f25e208e2a4da7fa306172b7aca557c1a521144329cd6059ceaab603b7944f552
> >
> > commons-net_commons-net-3.11.1.spdx.json=0ccf4994b061451d93d1225a8960483bbfcf5e87d03caac8ed0d7e7a6e815d07b34d76c401156b2246829a30554dcb61419a6766b35451ad12a6251fa0f1eef9
> >
> > 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.3" 2024-04-16
> > OpenJDK Runtime Environment Homebrew (build 21.0.3)
> > OpenJDK 64-Bit Server VM Homebrew (build 21.0.3, mixed mode, sharing)
> >
> > Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
> > Maven home: /usr/local/Cellar/maven/3.9.7/libexec
> > Java version: 21.0.3, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@21/21.0.3/libexec/openjdk.jdk/Contents/Home
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac"
> >
> > Darwin  23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:09:52
> > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64
> >
> > Details of changes since 3.11.0 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/net/3.11.1-RC1/RELEASE-NOTES.txt
> >
> > 

Re: [pool] Resilience against factory outages (POOL-407)

2024-05-31 Thread Gary D. Gregory
I updated the README's "Contributing" sections with:

+ Before you pushing a PR, run `mvn` (by itself), this runs the default goal, 
which contains all build checks.
+ To see the code coverage report, regardless of coverage failures, run `mvn 
clean site -Dcommons.jacoco.haltOnFailure=false`

This change will eventually make it other README files.

TY,
Gary

On 2024/05/31 20:44:51 "Gary D. Gregory" wrote:
> Hello Phil,
> 
> Before you push, run 'mvn' (buy itself), this runs the default goal, which 
> contains all build checks.
> 
> If see the code coverage report, regardless of coverage failures, run:
> 
> mvn clean site -Dcommons.jacoco.haltOnFailure=false
> 
> I'll update the readme...
> 
> TY,
> Gary
> 
> On 2024/05/31 20:12:09 Phil Steitz wrote:
> > The build worked locally for me fine.  I could not get the site to build.
> > Is there some sequence that I need to use to get the site to build?  I did
> > run Checksytle and Findbugs separately.  What is the test coverage plugin
> > and how do I run that?
> > 
> > Phil
> > 
> > On Fri, May 31, 2024 at 11:53 AM Gary Gregory 
> > wrote:
> > 
> > > Hi Phil,
> > >
> > > Thank you for the note. I'll try to take a look soon.
> > >
> > > The new code causes the build to fail as it looks like not all of it is
> > > covered by unit tests.
> > >
> > > Gary
> > >
> > >
> > > On Fri, May 31, 2024, 2:29 PM Phil Steitz  wrote:
> > >
> > > > I just committed  a first attempt at providing the above, intended as a
> > > fix
> > > > for POOL-407 and a lot of similar issues reported over the years.  The
> > > > scenario in POOL-407 is common when resource providers (like databases)
> > > go
> > > > down:
> > > >
> > > > 1. makeObject requests start to fail and threads line up waiting on the
> > > > deque.
> > > > 2. The provider comes back up so makes will succeed again, but the
> > > clients,
> > > > the pool and the factory are all ignorant of this fact, so no clients 
> > > > get
> > > > served.
> > > >
> > > > What I just committed puts the resilience responsibility on the factory,
> > > > having it monitor itself.  That responsibility could arguably be put
> > > > instead on the pool.
> > > >
> > > > To use the feature as is, you need to create a
> > > ResilientPooledObjectFactory
> > > > wrapping a PooledObjectFactory, configure it, attach it to its pool and
> > > > start its monitor.  The formerly disabled GOP test,
> > > > testLivenessOnTransientFactoryFailure, shows how to do it.  The setup is
> > > a
> > > > little awkward.  I would appreciate feedback on the following options 
> > > > for
> > > > how to improve it (or any other comments on the code):
> > > >
> > > > 0) Roll it back and come up with something better
> > > > 1) Leave as is
> > > > 2) add a GOP config that results in its factory being wrapped
> > > automatically
> > > > in a RPOF.
> > > > 3) move the functionality into the pool
> > > >
> > > > The other thing that needs to be designed is how to make the proactive
> > > make
> > > > attempt strategy configurable.  It is hard-coded now in the RPOF
> > > runChecks
> > > > and the Adder inner class.  The initial implementation is primitive:
> > > > Monitor the makeObject log.  Any failure triggers start of an Adder that
> > > > tries addObject with configurable delay and (hard-coded) max failures.
> > > > Once the circular log becomes filled with successes, turn the adder off.
> > > >
> > > > Also, RPOF spawns a monitoring thread and, when it detects a transient
> > > > failure, an adder thread.  Careful review - and improvement - of the
> > > > management of these threads would be appreciated.  I tried to make sure,
> > > > and added tests to confirm, that closing the pool kills these threads.
> > > >
> > > > Phil
> > > >
> > >
> > 
> 
> -
> 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] Resilience against factory outages (POOL-407)

2024-05-31 Thread Gary D. Gregory
Hello Phil,

Before you push, run 'mvn' (buy itself), this runs the default goal, which 
contains all build checks.

If see the code coverage report, regardless of coverage failures, run:

mvn clean site -Dcommons.jacoco.haltOnFailure=false

I'll update the readme...

TY,
Gary

On 2024/05/31 20:12:09 Phil Steitz wrote:
> The build worked locally for me fine.  I could not get the site to build.
> Is there some sequence that I need to use to get the site to build?  I did
> run Checksytle and Findbugs separately.  What is the test coverage plugin
> and how do I run that?
> 
> Phil
> 
> On Fri, May 31, 2024 at 11:53 AM Gary Gregory 
> wrote:
> 
> > Hi Phil,
> >
> > Thank you for the note. I'll try to take a look soon.
> >
> > The new code causes the build to fail as it looks like not all of it is
> > covered by unit tests.
> >
> > Gary
> >
> >
> > On Fri, May 31, 2024, 2:29 PM Phil Steitz  wrote:
> >
> > > I just committed  a first attempt at providing the above, intended as a
> > fix
> > > for POOL-407 and a lot of similar issues reported over the years.  The
> > > scenario in POOL-407 is common when resource providers (like databases)
> > go
> > > down:
> > >
> > > 1. makeObject requests start to fail and threads line up waiting on the
> > > deque.
> > > 2. The provider comes back up so makes will succeed again, but the
> > clients,
> > > the pool and the factory are all ignorant of this fact, so no clients get
> > > served.
> > >
> > > What I just committed puts the resilience responsibility on the factory,
> > > having it monitor itself.  That responsibility could arguably be put
> > > instead on the pool.
> > >
> > > To use the feature as is, you need to create a
> > ResilientPooledObjectFactory
> > > wrapping a PooledObjectFactory, configure it, attach it to its pool and
> > > start its monitor.  The formerly disabled GOP test,
> > > testLivenessOnTransientFactoryFailure, shows how to do it.  The setup is
> > a
> > > little awkward.  I would appreciate feedback on the following options for
> > > how to improve it (or any other comments on the code):
> > >
> > > 0) Roll it back and come up with something better
> > > 1) Leave as is
> > > 2) add a GOP config that results in its factory being wrapped
> > automatically
> > > in a RPOF.
> > > 3) move the functionality into the pool
> > >
> > > The other thing that needs to be designed is how to make the proactive
> > make
> > > attempt strategy configurable.  It is hard-coded now in the RPOF
> > runChecks
> > > and the Adder inner class.  The initial implementation is primitive:
> > > Monitor the makeObject log.  Any failure triggers start of an Adder that
> > > tries addObject with configurable delay and (hard-coded) max failures.
> > > Once the circular log becomes filled with successes, turn the adder off.
> > >
> > > Also, RPOF spawns a monitoring thread and, when it detects a transient
> > > failure, an adder thread.  Careful review - and improvement - of the
> > > management of these threads would be appreciated.  I tried to make sure,
> > > and added tests to confirm, that closing the pool kills these threads.
> > >
> > > Phil
> > >
> >
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats

2024-05-30 Thread Gary D. Gregory
I'm OK with Sebb's solution [1]

Any further thoughts here?

Gary
[1] https://github.com/apache/commons-lang/pull/1227

On 2024/05/29 13:37:40 Mike Drob wrote:
> On Wed, May 29, 2024 at 8:17 AM Gary Gregory  wrote:
> 
> > (Sorry for the top post, phone)
> >
> > A case I can imagine an empty '' occurring is when the format string itself
> > is built programmatically for example a '%s' or using string concatenate of
> > a variable that holds a string where that string can be empty or an "s" to
> > mark a plural or a quote for example.
> >
> > "He said '" + bla + "' to me and I waited mm minutes!"
> >
> > Far fetched? Sure 
> >
> > Gary
> >
> > On Wed, May 29, 2024, 8:43 AM sebb  wrote:
> >
> > > On Sun, 26 May 2024 at 23:37, sebb  wrote:
> > > >
> > > > On Sun, 26 May 2024 at 08:25, Laertes Moustakas 
> > > wrote:
> > > > >
> > > > > Hello Gary,
> > > > >
> > > > > Thank you for your response. Some of the new assertions indeed fail
> > > when interpreting the duplicate single quote as an escaped quote instead
> > of
> > > a closing and opening quote. In particular, "y' ''years' M 'months'" is
> > > interpreted as "4 'years 0 months" while the expected text lacks the
> > quote
> > > before "years". Same for "hello''world": it's interpreted as
> > "hello'world"
> > > instead of "helloworld".
> > > >
> > > > Please see https://github.com/apache/commons-lang/pull/1227 for an
> > > > alternate solution.
> > > > This does not cause issues with any existing tests.
> > > >
> > > > However, it does change the behaviour of a duplicate single quote
> > > > which is found outside an existing opening and closing quote.
> > > > Instead of the empty string, it generates a lone single quote.
> > > >
> > > > Whilst this is a change in behaviour, it seems to me that there should
> > > > be no need for anyone to use a format that uses a pair of adjacent
> > > > single quotes to generate an empty string in the output, so it seems
> > > > unlikely that this will cause any breakages.
> > >
> > > I've since realised that this argument could also apply to the
> > > existing test cases: is there really a use-case for adjacent constant
> > > strings?
> > > Why would anyone want to split a constant string in this way?
> 
> 
> This is similar to allowable string concatenation in Python, which static
> analysis flags as a warning and probable bug.
> https://pylint.pycqa.org/en/latest/user_guide/messages/warning/implicit-str-concat.html
> 
> 
> > > AFAICT it just makes it harder to read the string.
> > >
> > > i.e. do the test cases represent a real-world use case?
> > >
> > > > > I understand this brings forth a breaking change in formats that use
> > > two single quotes to close and open new literals (or even add an empty
> > > string), but this is consistent with what java.text.SimpleDateFormat
> > > expects. And I believe that most developers would favor consistency
> > between
> > > format strings in equivalent classes. Thus, I think the cases described
> > > above where the two single quotes terminate and begin a literal should no
> > > longer be supported.
> > >
> > > I agree.
> > >
> > > My alternate solution avoids breaking the test cases, but the downside
> > > is that the syntax is not in agreement with
> > > java.text.SimpleDateFormat, and is more verbose where a single-quote
> > > is to be inserted in an existing constant string (it requires 4 single
> > > quotes, rather than 2).
> > >
> > > > >
> > > > > Should this change go forward, I expect it to be part of a major
> > > release (e.g. version 4.0.0, 5.0.0, etc.) instead of 3.x.x, as it does
> > > contain a breaking change.
> > > > >
> > > > > If you have more questions, please don't hesitate to contact me.
> > > > >
> > > > > Best regards,
> > > > > Laertes
> > > > >
> > > > > On 2024/05/25 13:47:23 Gary Gregory wrote:
> > > > > > Hello Laertes,
> > > > > >
> > > > > > Thank you for your interest in improving Apache Commons Lang :-)
> > > > > >
> > > > > > Do you foresee any compatibility issues for existing call sites and
> > > > > > format strings?
> > > > > >
> > > > > > For example, can you make your use cases work and still support:
> > > > > >
> > > > > >
> > >
> > https://github.com/apache/commons-lang/blob/d861f1b2116a41a45949d1401785220119a57e56/src/test/java/org/apache/commons/lang3/time/DurationFormatUtilsTest.java#L463-L473
> > > > > >
> > > > > > Or, should these cases no longer be supported?
> > > > > >
> > > > > > TY!
> > > > > > Gary
> > > > > >
> > > > > > On Fri, May 24, 2024 at 4:15 PM Laertes Moustakas  > >
> > > wrote:
> > > > > > >
> > > > > > > Greetings,
> > > > > > >
> > > > > > > org.apache.commons.lang3.time.DurationFormatUtils contains useful
> > > methods
> > > > > > > to format a duration or period of milliseconds in the textual
> > > > > > > representation given by the format argument. It even allows
> > > arbitrary text
> > > > > > > to be printed between single quotes, on the condition that any
> > > opening
> > > > > > > single quotes 

Re: Javadoc usability

2024-05-26 Thread Gary D. Gregory
Emmanuel,

It looks like you updated the Commons Parent POM to add a profile without 
documenting the change in changes.xml. Would you please do that?

TY,
Gary

On 2024/05/18 12:21:54 sebb wrote:
> If we are changing the Javadoc settings, we should update the footer
> to include the full list of attributions.
> 
> On Sat, 18 May 2024 at 12:59, Emmanuel Bourg  wrote:
> >
> > Le 18/05/2024 à 13:07, Gary Gregory a écrit :
> > > You must be talking about this:
> > >
> > > https://bugs.openjdk.org/browse/JDK-8202961
> > >
> > > The frames command line option might be completely gone from the current
> > > Java version but I haven't tried
> >
> > Digging a bit, frames were deprecated in JDK 11 and eventually removed
> > in JDK 13 [1].
> >
> >
> > > I don't think we should use an antique version of the doclet.
> >
> > As long as a component doesn't require Java 13+ we could at least keep
> > the frames, for example by adding the -frame option to the javadoc
> > plugin configuration in the parent pom when building with JDK 11.
> >
> > Emmanuel Bourg
> >
> >
> > [1] https://bugs.openjdk.org/browse/JDK-8215599
> >
> >
> > -
> > 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: [VFS] Duplicate Listeners

2024-05-23 Thread Gary D. Gregory
Hi Bernd,

Thank you for researching this issue and presenting your findings.

In 2.9.0, we had (as you found):

public static void installListener(final FileObject file, final 
FileListener listener) {
final WeakRefFileListener weakListener = new WeakRefFileListener(file, 
listener);

file.getFileSystem().addListener(file, new WeakRefFileListener(file, 
weakListener));
}

Which already contains the "WeakRefFileListener in a WeakRefFileListener".

Unless I am missing something, the change in git master now just in inlines the 
local variable.

Are we saying that:
(1) We should not have a "WeakRefFileListener in a WeakRefFileListener"
(2) This problem already existed in 2.9.0.
(3) This problem existed when the class was introduced in 2.2 (despite the 2.0 
Javadoc since tag).

Let me know how you see it.

I can't say if your proposed change has any unintended side-effects; it should 
be accompanied with some kind of test, at the very least to avoid a regression.

TY!
Gary


On 2024/05/23 17:08:00 Bernd Eckenfels wrote:
> Hello,
> 
> I am dealing with a heapdump of VFS where I see a lot of WeakRefFileListener
> and all of them have a empty WeakRef to no listener. While I think I found the
> reason for that and fixed it on a dependent project, it still does not clean
> up correctly. I think the reason is that it does not store the WeakRefListener
> directly, but it stores a WeakReflistener of it. This will then immediatelly
> result in a unreferencedreferent - so it never works (it surely does fix the 
> leak :)
> 
> Gary, while cleaning up lint errors in fba04f3e5 you made a change, but I 
> asume it was
> only a mechanical replacement - or did you actually checkedif it is correct?
> 
> 
> https://github.com/apache/commons-vfs/blob/dc9ad7677a020b2d4c571f7dcc858cdbae2bb538/commons-vfs2/src/main/java/org/apache/commons/vfs2/util/WeakRefFileListener.java#L41
> 
> Cleaned up code:
> public static void installListener(final FileObject file, final FileListener 
> listener) {
> file.getFileSystem().addListener(file, new WeakRefFileListener(file, new 
> WeakRefFileListener(file, listener)));
> }
> 
> initial version:
> final WeakRefFileListener weakListener = new WeakRefFileListener(file, 
> listener);
> file.getFileSystem().addListener(file, new WeakRefFileListener(file, 
> weakListener));
> 
> 
> but I think it should be only a single wrapper:
> 
> public static void installListener(final FileObject file, final FileListener 
> listener) {
> file.getFileSystem().addListener(file, new WeakRefFileListener(file, 
> listener));
> }
> 
> There is a mention of VFS-143, but itintroduced the whole code with the 
> double indirection
> and it does not explain why it is needed.
> 
> What do you think, should we change it? 
> 
> I also wonder why no tests sees it (in factI try to add a test to reproduce 
> what I think
> shows its not working).
> 
> Gruss
> Bernd
> 
> -
> 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: (commons-lang) 01/02: Deprecate SystemUtils.getUserName(String) in favor of SystemProperties.getUserName(Supplier)

2024-05-02 Thread Gary D. Gregory
I meant I'll only change the Suppliers to Strings. The deprecations are fine 
IMO. This is how I see it:

- Stock system property access is done through SystemProperties (you get 
Strings)
- More advanced services that require conversions like getting a Stream of 
Paths for a java.class.path is done elsewhere. 
- For example, SystemUtils gives you the 'user.home' string as a File belongs 
where it is now: File file = SystemUtils.getUserHome(). I don't think we need a 
User class for example.

Gary

On 2024/05/02 18:57:04 "Gary D. Gregory" wrote:
> Hi Bernd,
> 
> Sounds reasonable. I'll revert the deprecation and use String defaults 
> instead of Suppliers.
> 
> Gary
> 
> On 2024/05/01 17:56:34 Bernd Eckenfels wrote:
> > Hi Gregory,
> > 
> > What’s the idea behind that deprecation? The implementation is robust and 
> > simple and easy to use. I would guess most user rather want to specify a 
> > literal fallback than a supplier.
> > 
> > Gruss
> > Bernd
> > 
> > ggreg...@apache.org wrote on 1. May 2024 16:07 (GMT +02:00):
> > 
> > > 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-lang.git
> > > 
> > > commit 794f8aaf1e5a573a63ba6ca514eeb794bd39d855
> > > Author: Gary Gregory 
> > > AuthorDate: Wed May 1 09:12:09 2024 -0400
> > > 
> > > Deprecate SystemUtils.getUserName(String) in favor of
> > > SystemProperties.getUserName(Supplier)
> > > ---
> > >  src/changes/changes.xml | 1 +
> > >  src/main/java/org/apache/commons/lang3/SystemUtils.java | 3 +++
> > >  2 files changed, 4 insertions(+)
> > > 
> > > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > > index cdd3a0cd0..1d896a999 100644
> > > --- a/src/changes/changes.xml
> > > +++ b/src/changes/changes.xml
> > > @@ -123,6 +123,7 @@ The  type attribute can be
> > > add,update,fix,remove.
> > >  Fix Java version in README.md #1170.
> > >  StringUtils.stripAccents() should handle
> > >  ligatures, UTF32 math blocks, etc. #1201.
> > >   > >  due-to="kijong.youn, Aakash Gupta, Gary
> > >  Gregory">TypeUtils.toString(Type) StackOverflowError for an inner
> > >  class in the inner class parameterized enclosing class #657.
> > > +Deprecate SystemUtils.getUserName(String) in favor of
> > > SystemProperties.getUserName(Supplier).
> > >  
> > >   > >  due-to="Dependabot">Bump commons-parent from 64 to 69 #1194.
> > >   > >  due-to="Dependabot">Bump org.codehaus.mojo:exec-maven-plugin from
> > >  3.1.1 to 3.2.0 #1175.
> > > diff --git a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > index cbb4721fb..8044fd4b0 100644
> > > --- a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > +++ b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > @@ -17,6 +17,7 @@
> > >  package org.apache.commons.lang3;
> > >  
> > >  import java.io.File;
> > > +import java.util.function.Supplier;
> > >  
> > >  /**
> > >   * Helpers for {@link System}.
> > > @@ -2041,7 +2042,9 @@ public class SystemUtils {
> > >   * access to the specified system property.
> > >   * @see SystemProperties#getUserName()
> > >   * @since 3.10
> > > + * @deprecated Use {@link SystemProperties#getUserName(Supplier)}.
> > >   */
> > > +@Deprecated
> > >  public static String getUserName(final String defaultValue) {
> > >  return System.getProperty(SystemProperties.USER_NAME,
> > >  defaultValue);
> > >  }
> > > 
> > > 
> > 
> > 
> > Gruß
> > Bernd
> > — 
> > https://bernd.eckenfels.net
> > 
> > -
> > 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: (commons-lang) 01/02: Deprecate SystemUtils.getUserName(String) in favor of SystemProperties.getUserName(Supplier)

2024-05-02 Thread Gary D. Gregory
Hello Elliotte,

OK, I'll use String defaults instead of Suppliers.

Gary

On 2024/05/02 16:48:48 Elliotte Rusty Harold wrote:
> I'm OK with preferring SystemProperties though I'm not sure that
> alpine justifies a new method and deprecation.
> 
> I second the opinion that a literal string is strongly preferable to a
> Supplier here. Pick the simplest thing that could possibly work. As
> Knuth warned us, premature optimization is the root of all evil in
> programming.
> 
> On Wed, May 1, 2024 at 1:56 PM Bernd Eckenfels  wrote:
> >
> > Hi Gregory,
> >
> > What’s the idea behind that deprecation? The implementation is robust and 
> > simple and easy to use. I would guess most user rather want to specify a 
> > literal fallback than a supplier.
> >
> > Gruss
> > Bernd
> >
> > ggreg...@apache.org wrote on 1. May 2024 16:07 (GMT +02:00):
> >
> > > 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-lang.git
> > >
> > > commit 794f8aaf1e5a573a63ba6ca514eeb794bd39d855
> > > Author: Gary Gregory 
> > > AuthorDate: Wed May 1 09:12:09 2024 -0400
> > >
> > > Deprecate SystemUtils.getUserName(String) in favor of
> > > SystemProperties.getUserName(Supplier)
> > > ---
> > >  src/changes/changes.xml | 1 +
> > >  src/main/java/org/apache/commons/lang3/SystemUtils.java | 3 +++
> > >  2 files changed, 4 insertions(+)
> > >
> > > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > > index cdd3a0cd0..1d896a999 100644
> > > --- a/src/changes/changes.xml
> > > +++ b/src/changes/changes.xml
> > > @@ -123,6 +123,7 @@ The  type attribute can be
> > > add,update,fix,remove.
> > >  Fix Java version in README.md #1170.
> > >  StringUtils.stripAccents() should handle
> > >  ligatures, UTF32 math blocks, etc. #1201.
> > >   > >  due-to="kijong.youn, Aakash Gupta, Gary
> > >  Gregory">TypeUtils.toString(Type) StackOverflowError for an inner
> > >  class in the inner class parameterized enclosing class #657.
> > > +Deprecate SystemUtils.getUserName(String) in favor of
> > > SystemProperties.getUserName(Supplier).
> > >  
> > >   > >  due-to="Dependabot">Bump commons-parent from 64 to 69 #1194.
> > >   > >  due-to="Dependabot">Bump org.codehaus.mojo:exec-maven-plugin from
> > >  3.1.1 to 3.2.0 #1175.
> > > diff --git a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > index cbb4721fb..8044fd4b0 100644
> > > --- a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > +++ b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > > @@ -17,6 +17,7 @@
> > >  package org.apache.commons.lang3;
> > >
> > >  import java.io.File;
> > > +import java.util.function.Supplier;
> > >
> > >  /**
> > >   * Helpers for {@link System}.
> > > @@ -2041,7 +2042,9 @@ public class SystemUtils {
> > >   * access to the specified system property.
> > >   * @see SystemProperties#getUserName()
> > >   * @since 3.10
> > > + * @deprecated Use {@link SystemProperties#getUserName(Supplier)}.
> > >   */
> > > +@Deprecated
> > >  public static String getUserName(final String defaultValue) {
> > >  return System.getProperty(SystemProperties.USER_NAME,
> > >  defaultValue);
> > >  }
> > >
> > >
> >
> >
> > Gruß
> > Bernd
> > —
> > https://bernd.eckenfels.net
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> 
> 
> -- 
> Elliotte Rusty Harold
> elh...@ibiblio.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: (commons-lang) 01/02: Deprecate SystemUtils.getUserName(String) in favor of SystemProperties.getUserName(Supplier)

2024-05-02 Thread Gary D. Gregory
Hi Bernd,

Sounds reasonable. I'll revert the deprecation and use String defaults instead 
of Suppliers.

Gary

On 2024/05/01 17:56:34 Bernd Eckenfels wrote:
> Hi Gregory,
> 
> What’s the idea behind that deprecation? The implementation is robust and 
> simple and easy to use. I would guess most user rather want to specify a 
> literal fallback than a supplier.
> 
> Gruss
> Bernd
> 
> ggreg...@apache.org wrote on 1. May 2024 16:07 (GMT +02:00):
> 
> > 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-lang.git
> > 
> > commit 794f8aaf1e5a573a63ba6ca514eeb794bd39d855
> > Author: Gary Gregory 
> > AuthorDate: Wed May 1 09:12:09 2024 -0400
> > 
> > Deprecate SystemUtils.getUserName(String) in favor of
> > SystemProperties.getUserName(Supplier)
> > ---
> >  src/changes/changes.xml | 1 +
> >  src/main/java/org/apache/commons/lang3/SystemUtils.java | 3 +++
> >  2 files changed, 4 insertions(+)
> > 
> > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > index cdd3a0cd0..1d896a999 100644
> > --- a/src/changes/changes.xml
> > +++ b/src/changes/changes.xml
> > @@ -123,6 +123,7 @@ The  type attribute can be
> > add,update,fix,remove.
> >  Fix Java version in README.md #1170.
> >  StringUtils.stripAccents() should handle
> >  ligatures, UTF32 math blocks, etc. #1201.
> >   >  due-to="kijong.youn, Aakash Gupta, Gary
> >  Gregory">TypeUtils.toString(Type) StackOverflowError for an inner
> >  class in the inner class parameterized enclosing class #657.
> > +Deprecate SystemUtils.getUserName(String) in favor of
> > SystemProperties.getUserName(Supplier).
> >  
> >   >  due-to="Dependabot">Bump commons-parent from 64 to 69 #1194.
> >   >  due-to="Dependabot">Bump org.codehaus.mojo:exec-maven-plugin from
> >  3.1.1 to 3.2.0 #1175.
> > diff --git a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > index cbb4721fb..8044fd4b0 100644
> > --- a/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > +++ b/src/main/java/org/apache/commons/lang3/SystemUtils.java
> > @@ -17,6 +17,7 @@
> >  package org.apache.commons.lang3;
> >  
> >  import java.io.File;
> > +import java.util.function.Supplier;
> >  
> >  /**
> >   * Helpers for {@link System}.
> > @@ -2041,7 +2042,9 @@ public class SystemUtils {
> >   * access to the specified system property.
> >   * @see SystemProperties#getUserName()
> >   * @since 3.10
> > + * @deprecated Use {@link SystemProperties#getUserName(Supplier)}.
> >   */
> > +@Deprecated
> >  public static String getUserName(final String defaultValue) {
> >  return System.getProperty(SystemProperties.USER_NAME,
> >  defaultValue);
> >  }
> > 
> > 
> 
> 
> Gruß
> Bernd
> — 
> https://bernd.eckenfels.net
> 
> -
> 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

2024-04-30 Thread Gary D. Gregory
Ping to the PMC for this thread and the Commons CSV one ;-)

Gary

On 2024/04/29 07:16:26 Thomas Vandahl wrote:
> Hi folks,
> 
> > 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)
> > 
> 
> Could I please ask for one more vote?
> 
> TIA
> Bye, Thomas 
> 
> 
> -
> 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 CSV 1.11.0 based on RC1

2024-04-30 Thread Gary D. Gregory
My +1

Gary


On 2024/04/28 22:24:13 Gary Gregory wrote:
> We have fixed a few bugs and added enhancements (better Microsoft
> Excel compatibility) since Apache Commons CSV 1.10.0 was released, so
> I would like to release Apache Commons CSV 1.11.0.
> 
> Apache Commons CSV 1.11.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/csv/1.11.0-RC1 (svn
> revision 68837)
> 
> The Git tag commons-csv-1.11.0-RC1 commit for this RC is
> 74e12741b24e724bb2e60109daa0c834fd75a68a which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-csv.git;a=commit;h=74e12741b24e724bb2e60109daa0c834fd75a68a
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-csv.git
> --branch commons-csv-1.11.0-RC1 commons-csv-1.11.0-RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1725/org/apache/commons/commons-csv/1.11.0/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Sun Apr 28 22:09:20 UTC 2024
> commons-csv-1.11.0-bin.tar.gz=5f822d8c2563a5692c72c1ac4cef9054d399753e77753ccb8a09cb847e60564c06603344f622219c86ee3f77bf355a23979d218520e6aa0a4750ba93a4882083
> commons-csv-1.11.0-bin.zip=62daab8fb3d00804d4ea02c3e61bd15d416d77895f7a0d06fe1744806396b3fa0343f7856770f30befaab2e8412eac03d888c78d29905e1b1752c5925f8fecc4
> commons-csv-1.11.0-bom.json=adb5e27d368e290848c29dce221711c20d01325c718110cb566d322a2a7b6430515b5057d24c2deadcd03fe3f07fa2ece6568ff3f9540dd018b858627f6143ef
> commons-csv-1.11.0-bom.xml=c8d4e04b288e86f65b1259f258b4c072aa2f38bffb0126aa0362bb03ddd7ab7613dd4ae094e74707be131735409aedfcc0268a6864890309f80b92b8ca96
> commons-csv-1.11.0-javadoc.jar=089477593f2f2de9b79bc78ea6aa51e09834a03a29b81e3d58225d1ee35e57baae35196b96d00c6bea8312007dafa7c9dfbd02cfb501f9b1f7830a3a65b1e1b3
> commons-csv-1.11.0-sources.jar=88b0216fc20675ff6f4e58e34b1f402c0a823bba86c39ff6661d009f950d6471715fdafbd0ffed0dd88c2ac5bc8120847ecf1e28385e66c1ff08b60f5d34411c
> commons-csv-1.11.0-src.tar.gz=6a59aa1f470e64117d63f52715bbc52c15544995f2a7beffc22c869bf3fd3ba870d654e58882c0d5c19a416e871119e53011b8efb7a89d34ded85b2642ed1e53
> commons-csv-1.11.0-src.zip=afab44f0cf0b884510cd4120b842ad3ccdea8ebe824e28b4504dfc5770c79f0589f335d8bae995e9457da0385918245a7483e9281ea2326e2c51a7fa089b1a6b
> commons-csv-1.11.0-test-sources.jar=569280d8db8bc7f1c651878981a64afa29c536233deefd11c50201cd34fe773347f60db58971c3056967a23d34fa24af85816d229f7ab101886ae3879db7e0c4
> commons-csv-1.11.0-tests.jar=62f010bbf91a39706f6c2fcd15935dbd8700c9003cff8e376c6265bde82acbe62952d686940a024b57a4ebd76c0f806d17e5d058aaa22ea2c995a28a4107a755
> org.apache.commons_commons-csv-1.11.0.spdx.json=5cc1f15e52e28f2f2e2eda9c3a1f9aab5089824d57eabeac03b00bbb137ab7d60ce2d90b7cc59bf7f0a3ebf474f2a8421d428ebe86dda7660e83ab1aa5c4bccd
> 
> I have tested this with 'mvn' and 'mvn -V -Prelease -Ptest-deploy -P
> jacoco -P japicmp clean package site deploy' using:
> 
> 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
> 
> Details of changes since 1.10.0 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/csv/1.11.0-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/csv/1.11.0-RC1/site/changes-report.html
> 
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/csv/1.11.0-RC1/site/index.html
> (note some *relative* links are broken and the 1.11.0 directories
> are not yet created - these will be OK once the site is deployed.)
> 
> JApiCmp Report (compared to 1.10.0):
> 
> https://dist.apache.org/repos/dist/dev/commons/csv/1.11.0-RC1/site/japicmp.html
> 
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/csv/1.11.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 

Re: [Collections] Suppliers, Iterables, and Producers

2024-04-30 Thread Gary D. Gregory



On 2024/04/30 14:33:47 Alex Herbert wrote:
> On Tue, 30 Apr 2024 at 14:45, Gary D. Gregory  wrote:
> 
> > Hi Claude,
> >
> > Thank you for the detailed reply :-) A few comments below.
> >
> > On 2024/04/30 06:29:38 Claude Warren wrote:
> > > I will see if I can clarify the javadocs and make things clearer.
> > >
> > > What I think I specifically heard is:
> > >
> > >- Be clear that producers are fast fail iterators with predicate
> > tests.
> > >- Rename CellConsumer to CellPredicate (?)
> >
> > Agreed (as suggested by Albert)
> >
> > >- The semantic nomenclature:
> > >   - Bitmaps are arrays of bits not a BitMap object.
> > >   - Indexes are ints and not an instance of a Collection object.
> > >   - Cells are pairs of ints representing an index and a value.  They
> > >   are not Pair<> objects.
> > >   - Producers iterate over collections of the object (Bitmap, Index,
> > >   Cell) applying a predicate to do work and stop the iteration early
> > if
> > >   necessary.  They are carriers/transporters of Bloom filter enabled
> > bits.
> > >   They allow us to query the contents of the Bloom filter in an
> > >   implementation agnostic way.
> >
> > As you say naming is hard. The above is a great example and a good
> > exercise I've gone through at work and in other FOSS projects: "Producers
> > iterate over collections of the object...". In general when I see or write
> > a Javadoc of the form "Foo bars" or "Runners walk" or "Walkers run", you
> > get the idea ;-) I know that either the class (or method) name is bad or
> > the Javadoc/documentation is bad; not _wrong_, just bad in the sense that
> > it's confusing (to me).
> >
> > I am not advocating for a specific change ATM but I want to discuss the
> > option because it is possible the current name is not as good as it could
> > be. It could end up as an acceptable compromise if we cannot use more Java
> > friendly terms though.
> >
> > Whenever I see a class that implements a "forEach"-kind of method, I think
> > "Iterable".
> >
> 
> Here we should think "Collection", or generally more than 1. In the Java
> sense an Iterable is something you can walk through to the
> end, possibly removing elements as you go using the Iterator interface. We
> would not require supporting removal, and we want to control a
> short-circuit. We could make this distinction by including it in the name:
> forEachUntil(Predicate ...), forEachUnless, ...

I really like the idea of have the method name reflect the short-circuit aspect 
of the operation!

We do not have to invent a new method name though, Stream uses 
"takeWhile(Predicate)" in Java 9: 
https://docs.oracle.com/javase/9/docs/api/java/util/stream/Stream.html#takeWhile-java.util.function.Predicate-

The question becomes whether this name make the class too close to a Stream and 
introduces some kind of confusion. If that's the case, then forEachUntil() is 
good.

> 
> 
> >
> > Note the difference with "Iterator", and I had to lookup the difference
> > since the former implements "forEach" and the  later "forEachRemaining"!
> > "Iterable" is also a factory of "Iterator"s.
> >
> > Should the Producers ever be implementations of Iterable or Iterator?
> > Right now, the answer is no because of the short-circuit aspect of using a
> > predicate. I'm not using the term fail-fast here because I don't think of
> > the iteration being in error (please tell me if I'm wrong).
> >
> > If not iterable, then we should not use that name as part of the class
> > name. Generally, the short-circuit aspect of Producers do not make a bad
> > candidates for implementations of Iterable since it can throw (unchecked)
> > exceptions. Different for call sites granted, but I'm just mentioning it
> > for fun.
> >
> 
> I already mentioned throwing runtime exceptions for the short-circuit
> functionality, and that it was ruled out on the basis of performance (given
> a lot of short-circuiting is expected) and convenience for the caller. I
> don't think we should go there. Design the API for the intended purpose,
> and not push it into a box that is easily recognisable.

Sounds good.

> 
> 
> >
> > So maybe there's nothing to do. I just want to be clear about it. For
> > example, I think of "factory" and "producer" as synonyms but in this case,
> > this is not a trad

Re: [Collections] Suppliers, Iterables, and Producers

2024-04-30 Thread Gary D. Gregory
Hi Claude,

Thank you for the detailed reply :-) A few comments below.

On 2024/04/30 06:29:38 Claude Warren wrote:
> I will see if I can clarify the javadocs and make things clearer.
> 
> What I think I specifically heard is:
> 
>- Be clear that producers are fast fail iterators with predicate tests.
>- Rename CellConsumer to CellPredicate (?)

Agreed (as suggested by Albert)

>- The semantic nomenclature:
>   - Bitmaps are arrays of bits not a BitMap object.
>   - Indexes are ints and not an instance of a Collection object.
>   - Cells are pairs of ints representing an index and a value.  They
>   are not Pair<> objects.
>   - Producers iterate over collections of the object (Bitmap, Index,
>   Cell) applying a predicate to do work and stop the iteration early if
>   necessary.  They are carriers/transporters of Bloom filter enabled bits.
>   They allow us to query the contents of the Bloom filter in an
>   implementation agnostic way.

As you say naming is hard. The above is a great example and a good exercise 
I've gone through at work and in other FOSS projects: "Producers iterate over 
collections of the object...". In general when I see or write a Javadoc of the 
form "Foo bars" or "Runners walk" or "Walkers run", you get the idea ;-) I know 
that either the class (or method) name is bad or the Javadoc/documentation is 
bad; not _wrong_, just bad in the sense that it's confusing (to me). 

I am not advocating for a specific change ATM but I want to discuss the option 
because it is possible the current name is not as good as it could be. It could 
end up as an acceptable compromise if we cannot use more Java friendly terms 
though.

Whenever I see a class that implements a "forEach"-kind of method, I think 
"Iterable".

Note the difference with "Iterator", and I had to lookup the difference since 
the former implements "forEach" and the  later "forEachRemaining"! "Iterable" 
is also a factory of "Iterator"s.

Should the Producers ever be implementations of Iterable or Iterator? Right 
now, the answer is no because of the short-circuit aspect of using a predicate. 
I'm not using the term fail-fast here because I don't think of the iteration 
being in error (please tell me if I'm wrong). 

If not iterable, then we should not use that name as part of the class name. 
Generally, the short-circuit aspect of Producers do not make a bad candidates 
for implementations of Iterable since it can throw (unchecked) exceptions. 
Different for call sites granted, but I'm just mentioning it for fun.

So maybe there's nothing to do. I just want to be clear about it. For example, 
I think of "factory" and "producer" as synonyms but in this case, this is not a 
traditional application of the factory pattern.

As an aside I can see that Producers would not be Streams out of the box 
because Stream#filter(Predicate) filters but does not short-circuit iteration. 
While Stream#findAny() and #findFirst() don't fit the short-circuit bill, we 
could implement a #findLast() in a Stream implementation. What I do not know is 
if Streams otherwise fit the bill of Bloom filters.

> 
> Does that basically cover the confusion?   If there are better terms, let's
> hash them out now before I update the javadocs.
> 
> As an aside, Cells and Bitmaps are referenced in the literature.  For the
> most part the rest is made up out of whole cloth.  So we could change
> "Producer" to something else but we would need a good name.

We have a class called BitMap and methods that use "BitMap" in the same but I 
think I am more comfortable with the term reuse now.

The question that remains is must it be public? Since the Javadoc mentions it 
is about indices and bit positions, could all these methods be moved to the 
package-private IndexUtils? My concern is to reduce the public and protected 
API surface we will have to support and keep for the lifetime of the 4.x code 
base.

> 
> Semantically:
> 
>- As Hasher generates an IndexProducer once it knows what the range of
>the values are and how many values it should produce (as defined in the
>Shape).  That index producer can be used multiple times and will produce
>the same set of values in the same order.
>- A Bloom filter generates an IndexProducer that enumerates the enabled
>bits in the filter.
>- A CellProducer generates an IndexProducer that reports all the index
>values that it contains.
> 
> In implementing stable Bloom filters I had to create a RandomHasher that
> generates an IndexProducer that will generate values in the range and
> number specified by the Shape but that does not produce the same values
> every time (obviously).
> 
> We could change Producer to a term that means a representation: Ideogram,
> but then we have to introduce the term and explain what it means.  Producer
> starts at a common point.
> 
> All of this just goes to show that "Naming things is hard".  But then we
> all knew that 

Re: [CONFIGURATION] ParseException does not exist

2024-04-26 Thread Gary D. Gregory
Hello Ricardo,

The build is green now:

https://github.com/apache/commons-configuration/actions

The error you found was just a temporary snafu ;-)

Gary

On 2024/04/24 18:01:24 Ricardo Mendes wrote:
> Hey,
> 
> Not sure if this is the right place to ask, but I just recently forked 
> configuration and I just wanted to build it on my local.
> 
> I ran mvn as described in the README
> [cid:c6c1beea-0d5e-4f38-ac81-512fbccb7be6]
> 
> But for some reason ParseException does not exist in the project.
> [cid:cc371705-9aa4-4d72-b8f1-af45d39c564b]
> 
> I went on GitHub and couldn't find the class at all and noticed that 19 hours 
> ago the build failed.
> 
> https://github.com/apache/commons-configuration/tree/master/src/main/java/org/apache/commons/configuration2/plist
> 
> [cid:2988b41a-b185-420c-a291-40e348181258]
> 
> And I see all this changes
> [cid:e260da9f-8611-4ecf-8a3b-ccf0eda56110]
> Sort members · apache/commons-configuration@8119b6b 
> (github.com)
> 
> Failed Build
> [cid:368cf2fc-b5d9-4985-8a98-443279c1f714]
> 
> [cid:4eb94541-4d30-418f-9c81-8edc5824b405]
> 
> Can someone help me and shed some light? Is everything ok?
> 
> https://github.com/apache/commons-configuration/actions/runs/8808146511/job/24176639346
> 
> Ever thankful
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [VOTE] Release Apache Commons BCEL 6.9.0 based on RC1

2024-04-25 Thread Gary D. Gregory
Ping :-)

On 2024/04/22 18:48:21 Bruno Kinoshita wrote:
> +1
> 
> Building OK from tag on
> 
> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> Maven home: /opt/apache-maven-3.8.5
> Java version: 17.0.10, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-105-generic", arch: "amd64", family:
> "unix"
> 
> 
> 
> On Sun, 21 Apr 2024 at 19:20, Gary Gregory  wrote:
> 
> > We have fixed a few bugs and one enhancement (Java 16 records) since
> > Apache Commons BCEL 6.8.2 was released, so I would like to release
> > Apache Commons BCEL 6.9.0.
> >
> > Apache Commons BCEL 6.9.0 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.9.0-RC1 (svn
> > revision 68692)
> >
> > The Git tag commons-bcel-6.9.0-RC1 commit for this RC is
> > c240a615d2fcb2497c7d77ad3993e4c66c16e03a which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=c240a615d2fcb2497c7d77ad3993e4c66c16e03a
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> > --branch 
> > commons-bcel-6.9.0-RC1 commons-bcel-6.9.0-RC1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1724/org/apache/bcel/bcel/6.9.0/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Sun Apr 21 17:07:12 UTC 2024
> >
> > bcel-6.9.0-bin.tar.gz=e2ac07716a8203405040a18e6dddb84445c0cbc874da382fc67b082c20f3659228ecabf6cba3fbe83b60d36d08c2d9493dfd731960f5aec073f87d9f2e8126f2
> >
> > bcel-6.9.0-bin.zip=93efcf6194077fc216ca81a0f37ca6dc2f5e4032483cfee34c789fe859917be0924221c502ed886fb4582e3681907e73e4f5af11591d1d6a6b2fd779b871bbda
> >
> > bcel-6.9.0-bom.json=4c085990c8b5ece5092f8032b56fd7c87a686443f37b04a2701904b37d7fb1f7147013f82110d67b12d449b78d4743634112f5fa9bfa80de03ec71a06755d934
> >
> > bcel-6.9.0-bom.xml=5759c53a32588f25d672daf90955cee7e2f21a60d98b06a2a8d0fb15ff5308f90885a87eadfbd835cb5b86c856866daac5af04f6723d28495118e984d1d3eff4
> >
> > bcel-6.9.0-javadoc.jar=ac65e56220c0b8fffd67d03a2b003631c34742f33e385249a3b9c511fce50574771afc800ae6d8521ef6195cfc0f448f64b7b7b21a4d80cfe6ba7af86dd1fb19
> >
> > bcel-6.9.0-sources.jar=5e9f448c48604edbfcc2416994649d118e58de596212cd034dc21895277829f8540e43f76f3e45396fa29a060b17b1e1b9086068043131e7f771213449a18349
> >
> > bcel-6.9.0-src.tar.gz=d0a7099257ee30e1ff56896d3d855ba03d2d3efb92a9ac0fba7464ef3052ab26ad7c8ed3a37e551ad5f944a0f04cc811047b20f90c81133ab9aaa008bf517da4
> >
> > bcel-6.9.0-src.zip=37b632c1f921a8aa476571085ce43bdf63db8150a94640775c7bc56d737613cd24e5531a236223ab3ee2e0b15416f3a5722012edd126defdd0f5f8e6ea6c11d0
> >
> > bcel-6.9.0-test-sources.jar=9f9d9a56fb477f767ac9d3e7637a4ef1de032d70594bba3c0999b8a616de73d3ba590f32a154d2699efb0ae2a0932e97229e2dba25758402b6412112086afb95
> >
> > bcel-6.9.0-tests.jar=f645062309b71990440ada1b7cea4b37a24eadcefbe7e0c7a2358905516d713172704c8cfe6f765d89bf8e4a60bfa51096b42efebbe0b5a249f7dc3fecad3e4c
> >
> > org.apache.bcel_bcel-6.9.0.spdx.json=52ee76059ef22938aabbe6fb62d3d71bc3289d38c2b2cac4ddb415b8e7603c90af9cad33baa9d583f6baf96c1206b66c85fb5576e372473cf3ec1939f3792ea9
> >
> >
> >
> > I have tested this with 'mvn' and 'mvn -V -Prelease -Ptest-deploy -P
> > jacoco -P japicmp clean package site deploy' using:
> >
> > 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
> >
> > Details of changes since 6.8.2 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.9.0-RC1/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.9.0-RC1/site/changes-report.html
> >
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.9.0-RC1/site/index.html
> > (note some *relative* links are broken and the 6.9.0 directories
> > are not yet created - these will be OK once the site is deployed.)
> >
> > JApiCmp Report (compared to 6.8.2):
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.9.0-RC1/site/japicmp.html
> >
> > RAT Report:
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.9.0-RC1/site/rat-report.html
> >
> > KEYS:
> > https://downloads.apache.org/commons/KEYS
> >
> > Please review the release 

[Collections] Bloom filter package's Hasher to extend Function

2024-04-25 Thread Gary D. Gregory
Hi Clause, Albert, and all,

Why not make Hasher more functional like so:

public interface Hasher extends Function

It would implement the standard `apply` instead of `indices`.

WDYT?

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



[ALL] GitHub is done with Java 8

2024-04-24 Thread Gary D. Gregory
Hi All,

I just saw this on GitHub for our Lang component:

Error: Could not find satisfied version for SemVer '8'. 

Available versions: 22.0.1+8, 22.0.0+36, 21.0.3+9.0.LTS, 21.0.2+13.0.LTS, 
21.0.1+12.0.LTS, 21.0.0+35.0.LTS, 20.0.2+9, 20.0.1+9, 20.0.0+36, 19.0.2+7, 
19.0.1+10, 19.0.0+36, 18.0.2+101, 18.0.2+9, 18.0.1+10, 18.0.0+36, 17.0.11+9, 
17.0.10+7, 17.0.9+9, 17.0.8+101, 17.0.8+7, 17.0.7+7, 17.0.6+10, 17.0.5+8, 
17.0.4+101, 17.0.4+8, 17.0.3+7, 17.0.2+8, 17.0.1+12, 17.0.0+35, 11.0.23+9, 
11.0.22+7.1, 11.0.22+7, 11.0.21+9, 11.0.20+101, 11.0.20+8, 11.0.19+7, 
11.0.18+10, 11.0.17+8, 11.0.16+101, 11.0.16+8, 11.0.15+10

So it looks like goodbye Java 8 on GitHub.

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [VOTE] Release Apache Commons BCEL 6.9.0 based on RC1

2024-04-22 Thread Gary D. Gregory
My +1

Gary

On 2024/04/21 17:19:58 Gary Gregory wrote:
> We have fixed a few bugs and one enhancement (Java 16 records) since
> Apache Commons BCEL 6.8.2 was released, so I would like to release
> Apache Commons BCEL 6.9.0.
> 
> Apache Commons BCEL 6.9.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.9.0-RC1 (svn
> revision 68692)
> 
> The Git tag commons-bcel-6.9.0-RC1 commit for this RC is
> c240a615d2fcb2497c7d77ad3993e4c66c16e03a which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=c240a615d2fcb2497c7d77ad3993e4c66c16e03a
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> --branch commons-bcel-6.9.0-RC1 commons-bcel-6.9.0-RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1724/org/apache/bcel/bcel/6.9.0/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Sun Apr 21 17:07:12 UTC 2024
> bcel-6.9.0-bin.tar.gz=e2ac07716a8203405040a18e6dddb84445c0cbc874da382fc67b082c20f3659228ecabf6cba3fbe83b60d36d08c2d9493dfd731960f5aec073f87d9f2e8126f2
> bcel-6.9.0-bin.zip=93efcf6194077fc216ca81a0f37ca6dc2f5e4032483cfee34c789fe859917be0924221c502ed886fb4582e3681907e73e4f5af11591d1d6a6b2fd779b871bbda
> bcel-6.9.0-bom.json=4c085990c8b5ece5092f8032b56fd7c87a686443f37b04a2701904b37d7fb1f7147013f82110d67b12d449b78d4743634112f5fa9bfa80de03ec71a06755d934
> bcel-6.9.0-bom.xml=5759c53a32588f25d672daf90955cee7e2f21a60d98b06a2a8d0fb15ff5308f90885a87eadfbd835cb5b86c856866daac5af04f6723d28495118e984d1d3eff4
> bcel-6.9.0-javadoc.jar=ac65e56220c0b8fffd67d03a2b003631c34742f33e385249a3b9c511fce50574771afc800ae6d8521ef6195cfc0f448f64b7b7b21a4d80cfe6ba7af86dd1fb19
> bcel-6.9.0-sources.jar=5e9f448c48604edbfcc2416994649d118e58de596212cd034dc21895277829f8540e43f76f3e45396fa29a060b17b1e1b9086068043131e7f771213449a18349
> bcel-6.9.0-src.tar.gz=d0a7099257ee30e1ff56896d3d855ba03d2d3efb92a9ac0fba7464ef3052ab26ad7c8ed3a37e551ad5f944a0f04cc811047b20f90c81133ab9aaa008bf517da4
> bcel-6.9.0-src.zip=37b632c1f921a8aa476571085ce43bdf63db8150a94640775c7bc56d737613cd24e5531a236223ab3ee2e0b15416f3a5722012edd126defdd0f5f8e6ea6c11d0
> bcel-6.9.0-test-sources.jar=9f9d9a56fb477f767ac9d3e7637a4ef1de032d70594bba3c0999b8a616de73d3ba590f32a154d2699efb0ae2a0932e97229e2dba25758402b6412112086afb95
> bcel-6.9.0-tests.jar=f645062309b71990440ada1b7cea4b37a24eadcefbe7e0c7a2358905516d713172704c8cfe6f765d89bf8e4a60bfa51096b42efebbe0b5a249f7dc3fecad3e4c
> org.apache.bcel_bcel-6.9.0.spdx.json=52ee76059ef22938aabbe6fb62d3d71bc3289d38c2b2cac4ddb415b8e7603c90af9cad33baa9d583f6baf96c1206b66c85fb5576e372473cf3ec1939f3792ea9
> 
> 
> 
> I have tested this with 'mvn' and 'mvn -V -Prelease -Ptest-deploy -P
> jacoco -P japicmp clean package site deploy' using:
> 
> 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
> 
> Details of changes since 6.8.2 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.9.0-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.9.0-RC1/site/changes-report.html
> 
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.9.0-RC1/site/index.html
> (note some *relative* links are broken and the 6.9.0 directories
> are not yet created - these will be OK once the site is deployed.)
> 
> JApiCmp Report (compared to 6.8.2):
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.9.0-RC1/site/japicmp.html
> 
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.9.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 

Re: [VOTE] Release Apache Commons JCS 3.2.1 based on rc2

2024-04-20 Thread 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
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: [jcs] multicast issues, was: Re: [VOTE] Release Apache Commons JCS 3.2.1 based on rc1

2024-04-07 Thread Gary D. Gregory
Hi Thomas,

OK, here we go:

VPN on (Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for 
Windows x64)
git checkout fe20ca994803b353c32fd0909621d822ee26263c
mvn clean test -Dtest=UDPDiscoverySenderEncryptedUnitTest

Same 3 failures, log: https://paste.apache.org/grnpx

TY!
Gary

On 2024/04/07 17:04:15 Thomas Vandahl wrote:
> (trying to move this out of the vote thread)
> 
> Hi Gary,
> 
> > Am 07.04.2024 um 14:33 schrieb Gary D. Gregory :
> > 
> > Hi Thomas,
> > 
> > Ran:
> > 
> > mvn test -Dtest=UDPDiscoverySenderEncryptedUnitTest
> > 
> > Log: 
> > 
> > https://paste.apache.org/1hmkb
> 
> Thank you. Could you please make sure that you are at commit 
> fe20ca994803b353c32fd0909621d822ee26263c ?
> I don't see the debug messages from HostNameUtil where I added the check for 
> multicast support. 
> 
> If the code is current, that would imply that the Cisco adapter lies about 
> its multicast support and that we cannot rely on the JDK to configure the 
> tests. That would be really bad news.
> 
> Bye, Thomas 
> -
> 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 rc1

2024-04-07 Thread Gary D. Gregory
Hi Thomas,

Ran:

mvn test -Dtest=UDPDiscoverySenderEncryptedUnitTest

Log: 

https://paste.apache.org/1hmkb

Gary

On 2024/04/06 20:06:47 Thomas Vandahl wrote:
> Hi Gary,
> 
> > Am 06.04.2024 um 17:20 schrieb Gary D. Gregory :
> > 
> > Switching to origin/release-3.2.1 lets me run the default Maven goal (just 
> > 'mvn') to successfully to completion!
> > 
> 
> May I kindly ask for the debug log again? I'd like to know whether JCS can 
> find a valid multicast interface even if the VPN is on.
> 
> Bye, Thomas 
> 
> 
> -
> 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 rc1

2024-04-06 Thread Gary D. Gregory
And to confirm that VPN is the issue, I reconnected and got:

[ERROR] Failures:
[ERROR]   UDPDiscoverySenderEncryptedUnitTest.testPassiveBroadcast:116 message 
not received
[ERROR]   UDPDiscoverySenderEncryptedUnitTest.testRemoveBroadcast:138 message 
not received
[ERROR]   UDPDiscoverySenderEncryptedUnitTest.testRequestBroadcast:157 message 
not received

So that's one for the release notes!

Gary

On 2024/04/06 15:20:43 "Gary D. Gregory" wrote:
> Ah, I was on git master on Windows, which without the VPN, now hangs in:
> 
> [INFO] Running 
> org.apache.commons.jcs3.auxiliary.disk.indexed.IndexedDiskCacheConcurrentNoDeadLockUnitTest
> 
> Switching to origin/release-3.2.1 lets me run the default Maven goal (just 
> 'mvn') to successfully to completion!
> 
> Gary
> 
> On 2024/04/06 14:57:50 Thomas Vandahl wrote:
> > Hi Gary,
> > 
> > > Am 06.04.2024 um 15:07 schrieb Gary D. Gregory :
> > > 
> > > mvn test -Dtest=UDPDiscoverySenderEncryptedUnitTest
> > > 
> > > which failed with the log here: https://paste.apache.org/b4p09
> > 
> > Please check out from branch release-3.2.1 and try again. 
> > 
> > Bye, Thomas 
> > 
> > 
> > -
> > 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: [VOTE] Release Apache Commons JCS 3.2.1 based on rc1

2024-04-06 Thread Gary D. Gregory
Ah, I was on git master on Windows, which without the VPN, now hangs in:

[INFO] Running 
org.apache.commons.jcs3.auxiliary.disk.indexed.IndexedDiskCacheConcurrentNoDeadLockUnitTest

Switching to origin/release-3.2.1 lets me run the default Maven goal (just 
'mvn') to successfully to completion!

Gary

On 2024/04/06 14:57:50 Thomas Vandahl wrote:
> Hi Gary,
> 
> > Am 06.04.2024 um 15:07 schrieb Gary D. Gregory :
> > 
> > mvn test -Dtest=UDPDiscoverySenderEncryptedUnitTest
> > 
> > which failed with the log here: https://paste.apache.org/b4p09
> 
> Please check out from branch release-3.2.1 and try again. 
> 
> Bye, Thomas 
> 
> 
> -
> 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 rc1

2024-04-06 Thread Gary D. Gregory
Thomas,

Running 'mvn clean verify -pl commons-jcs3-core' fails as usual (git master). 

The class UDPDiscoverySenderUnitTest is _excluded_ in the POM so it does not 
even run.

I edited logging.properties:

handlers=java.util.logging.FileHandler

.level = FINER

java.util.logging.FileHandler.level=FINER
java.util.logging.FileHandler.pattern=target/jcs-logging-%g.log
java.util.logging.FileHandler.limit = 10
java.util.logging.FileHandler.count = 2
java.util.logging.FileHandler.append=true
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
java.util.logging.SimpleFormatter.format=[%1$tF %1$tT] %3$s [%4$-7s] %5$s %n

and ran:

mvn test -Dtest=UDPDiscoverySenderEncryptedUnitTest

which failed with the log here: https://paste.apache.org/b4p09

TY,
Gary


On 2024/04/06 12:46:20 Thomas Vandahl wrote:
> Hi Gary,
> 
> > Am 06.04.2024 um 14:10 schrieb Gary D. Gregory :
> > 
> > Hi Thomas,
> > 
> > I ran:
> > 
> > mvn test -Dtest=UDPDiscoverySenderUnitTest -X >\test\out.txt
> > 
> > and killed it after 10 minutes since it never finished. I tried 3 times.
> 
> Thanks. Not good. 
> Could you please repeat the test with the log levels in 
> /commons-jcs3-core/src/test/test-conf/logging.properties set to FINER and 
> send me the content of target/jcs-logging-0.log?
> 
> Does this test run successfully when you run mvn clean verify for 
> commons-jcs3-core?
> 
> Bye, Thomas 
> -
> 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 rc1

2024-04-06 Thread Gary D. Gregory
Hi Thomas,

I ran:

mvn test -Dtest=UDPDiscoverySenderUnitTest -X >\test\out.txt

and killed it after 10 minutes since it never finished. I tried 3 times.

See https://paste.apache.org/0d08b

TY,
Gary

On 2024/04/06 10:02:36 Thomas Vandahl wrote:
> Hi Gary,
> 
> > Am 05.04.2024 um 17:28 schrieb Gary D. Gregory :
> > 
> > [INFO] Running 
> > org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest
> > [ERROR] Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 
> > 9.526 s <<< FAILURE! - in 
> > org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest
> > [ERROR] 
> > org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest.testRequestBroadcast
> >   Time elapsed: 3.36 s  <<< FAILURE!
> 
> Could you please check that the test 
> org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderUnitTest runs fine 
> on Windows under all circumstances? If so, we would need to look at 
> org.apache.commons.jcs3.utils.serialization.EncryptingSerializer because that 
> is the only difference between the two tests.
> 
> Bye, Thomas 
> 
> 
> -
> 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 rc1

2024-04-05 Thread Gary D. Gregory
Rob, 

What OS and such (mvn -version)?

Gary

On 2024/04/05 14:51:39 Rob Tompkins wrote:
> -0.5: building with java17 from the src zip I get the following for the 
> jcs-core module
> 
> [INFO] Results:
> [INFO] 
> [ERROR] Failures: 
> [ERROR]   UDPDiscoverySenderEncryptedUnitTest.testPassiveBroadcast:116 
> message not received
> [ERROR]   UDPDiscoverySenderEncryptedUnitTest.testRemoveBroadcast:138 message 
> not received
> [ERROR]   UDPDiscoverySenderEncryptedUnitTest.testRequestBroadcast:157 
> message not received
> [INFO] 
> [ERROR] Tests run: 426, Failures: 3, Errors: 0, Skipped: 0
> 
> 
> -Rob
> 
> > On Apr 4, 2024, at 10:49 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 rc1 is available for review here:
> >https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc1 (svn 
> > revision 68312)
> > 
> > The Git tag commons-jcs3-3.2.1-rc1 commit for this RC is 
> > 0b20664b6c60b025cfe0e95c33e86f3239822a12 which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=0b20664b6c60b025cfe0e95c33e86f3239822a12
> > You may checkout this tag using:
> >git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch 
> > commons-jcs3-3.2.1-rc1 commons-jcs3-3.2.1-rc1
> > 
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1712/org/apache/commons/commons-jcs3/3.2.1/
> > 
> > These are the artifacts and their hashes:
> > 
> > 5ea0cfd1ea5d17689ce35fd4a26ad104028b2b0d3209cf8c3d58d1a8e62c77442de95d51af278ad810a28117d0297725ded41b18553e05212dfc9e9db1dd185c
> >   commons-jcs3-dist-3.2.1-bin.tar.gz
> > ce7151767ebcf5ce08c9e91689ef1b240344b874963edc3042c0a6958e02deb95551aa9de1a8f63fd6e87198f179ad90501a0b76f96cf6c2c10cd546e867c8bf
> >   commons-jcs3-dist-3.2.1-bin.zip
> > 8abc08f18edf6fcd86d9fcb8834ef4584d6932a6a7dca8936b199b6aec3622e634c20f639fdb5cd1077d2492e1a8fd3dafb0ceb9a259127c3dfc3ec54d6cea1b
> >   commons-jcs3-dist-3.2.1-src.tar.gz
> > e7a2796bc07b9da4d8e5db0423baa758e0e139e8cdc35aa6d50e32cdfa9163b874eeedfd52e90c599049faa1963546109389fb967e60df8a0198a025a3d75869
> >   commons-jcs3-dist-3.2.1-src.zip
> > 
> > I have tested this with ***'mvn clean install site'*** using:
> > 
> > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> > Java version: 1.8.0_311, vendor: Oracle Corporation, runtime: 
> > /Library/Java/JavaVirtualMachines/jdk1.8.0_311.jdk/Contents/Home/jre
> > Default locale: de_DE, platform encoding: UTF-8
> > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
> > 
> > Details of changes since 3.2 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc1/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc1/site/changes-report.html
> > 
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc1/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-rc1/site/commons-jcs3-core/japicmp.html
> > RAT Report:
> >
> > https://dist.apache.org/repos/dist/dev/commons/jcs/3.2.1-rc1/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,
> > 
> > Bye, Thomas 
> > 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
> 
> 

-
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 rc1

2024-04-05 Thread Gary D. Gregory
at 
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169)
at 
org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581)

[ERROR] 
org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest.testPassiveBroadcast
  Time elapsed: 3.055 s  <<< FAILURE!
junit.framework.AssertionFailedError: message not received
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNotNull(Assert.java:256)
at junit.framework.TestCase.assertNotNull(TestCase.java:399)
at 
org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest.testPassiveBroadcast(UDPDiscoverySenderEncryptedUnitTest.java:116)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at junit.framework.TestCase.runTest(TestCase.java:177)
at junit.framework.TestCase.runBare(TestCase.java:142)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:130)
at junit.framework.TestSuite.runTest(TestSuite.java:241)
at junit.framework.TestSuite.run(TestSuite.java:236)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:90)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:377)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:284)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:248)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:167)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456)
at 
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169)
at 
org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581)

Gary


On 2024/04/05 13:51:39 Thomas Vandahl wrote:
> Hi Gary,
> 
> > Am 04.04.2024 um 22:30 schrieb Gary D. Gregory :
> > 
> > After being successful on macOS, I am seeing the following _repeatable_ 
> > failures on Windows 10 running the default Maven goal (just `mvn`):
> > 
> > ...
> > [INFO] Running 
> > org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest
> > [ERROR] Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 
> > 9.339 s <<< FAILURE! - in 
> > org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest
> > [ERROR] 
> > org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest.testRequestBroadcast
> >   Time elapsed: 3.23 s  <<< FAILURE!
> > junit.framework.AssertionFailedError: message not received
> 
> This code has not been touched since 3.2. Could you please verify that this 
> problem is also present in 3.2?
> 
> Bye, Thomas 
> 
> 
> -
> 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 rc1

2024-04-05 Thread Gary D. Gregory
FTR, on Linux running inside Windows (WSL), the build works for me using:

Linux RS-PF3NRMLR 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 
UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /mnt/c/java/apache-maven-3.9.6
Java version: 17.0.10, vendor: Private Build, runtime: 
/usr/lib/jvm/java-17-openjdk-amd64
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.15.133.1-microsoft-standard-wsl2", arch: "amd64", 
family: "unix"

So we only have the Windows build to figure out, macOS and Linux are OK for me.

Gary

On 2024/04/04 19:46:29 Bruno Kinoshita wrote:
> Hi Thomas,
> 
> The build is not working for me. Are you able to tell me what could be
> wrong with my environment, please?
> 
> commit 0b20664b6c60b025cfe0e95c33e86f3239822a12 (HEAD, tag:
> commons-jcs3-3.2.1-rc1)
> Author: Thomas Vandahl 
> Date:   Thu Apr 4 14:47:16 2024 +0200
> 
> [maven-release-plugin] prepare release commons-jcs3-3.2.1-rc1
> 
> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> Maven home: /opt/apache-maven-3.8.5
> Java version: 17.0.10, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-101-generic", arch: "amd64", family:
> "unix"
> 
> `mvn clean install site`
> 
> [INFO]
> 
> [INFO] Reactor Summary for Apache Commons JCS 3.2.1:
> [INFO]
> [INFO] Apache Commons JCS . FAILURE [01:23
> min]
> [INFO] Apache Commons JCS :: Core . SKIPPED
> [INFO] Apache Commons JCS :: JCache ... SKIPPED
> [INFO] Apache Commons JCS :: JCache TCK ... SKIPPED
> [INFO] Apache Commons JCS :: JCache Extras  SKIPPED
> [INFO] Apache Commons JCS :: JCache OpenJPA ... SKIPPED
> [INFO] Apache Commons JCS :: Distribution . SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  01:23 min
> [INFO] Finished at: 2024-04-04T20:32:15+02:00
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.12.1:site (default-site) on
> project commons-jcs3: Error generating
> maven-project-info-reports-plugin:3.4.3:dependency-convergence report:
> Could not build dependency tree: Could not collect dependencies:
> org.apache.commons:commons-jcs3-jcache-openjpa:jar:3.2.1: Failed to collect
> dependencies at org.apache.openjpa:openjpa:jar:2.4.3 ->
> org.apache.openjpa:openjpa-kernel:jar:2.4.3 ->
> com.ibm.websphere:websphere_uow_api:jar:0.0.1: Failed to read artifact
> descriptor for com.ibm.websphere:websphere_uow_api:jar:0.0.1: Could not
> transfer artifact com.ibm.websphere:websphere_uow_api:pom:0.0.1 from/to
> openjpa-internal (file://${basedir}/internal-repository): Repository path
> /internal-repository does not exist, and cannot be created. -> [Help 1]
> 
> On Thu, 4 Apr 2024 at 17:36, Thomas Vandahl  wrote:
> 
> > My vote:
> >
> > > Am 04.04.2024 um 16:49 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.
> > >
> > >  [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
> >
> >
> 

-
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 rc1

2024-04-04 Thread Gary D. Gregory
After being successful on macOS, I am seeing the following _repeatable_ 
failures on Windows 10 running the default Maven goal (just `mvn`):

...
[INFO] Running 
org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest
[ERROR] Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 9.339 s 
<<< FAILURE! - in 
org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest
[ERROR] 
org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest.testRequestBroadcast
  Time elapsed: 3.23 s  <<< FAILURE!
junit.framework.AssertionFailedError: message not received
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNotNull(Assert.java:256)
at junit.framework.TestCase.assertNotNull(TestCase.java:399)
at 
org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest.testRequestBroadcast(UDPDiscoverySenderEncryptedUnitTest.java:157)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at junit.framework.TestCase.runTest(TestCase.java:177)
at junit.framework.TestCase.runBare(TestCase.java:142)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:130)
at junit.framework.TestSuite.runTest(TestSuite.java:241)
at junit.framework.TestSuite.run(TestSuite.java:236)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:90)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:316)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
at 
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
at 
org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)

[ERROR] 
org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest.testRemoveBroadcast
  Time elapsed: 3.033 s  <<< FAILURE!
junit.framework.AssertionFailedError: message not received
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNotNull(Assert.java:256)
at junit.framework.TestCase.assertNotNull(TestCase.java:399)
at 
org.apache.commons.jcs3.utils.discovery.UDPDiscoverySenderEncryptedUnitTest.testRemoveBroadcast(UDPDiscoverySenderEncryptedUnitTest.java:138)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at junit.framework.TestCase.runTest(TestCase.java:177)
at junit.framework.TestCase.runBare(TestCase.java:142)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:130)
at junit.framework.TestSuite.runTest(TestSuite.java:241)
at junit.framework.TestSuite.run(TestSuite.java:236)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:90)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:316)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
at 
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
at 

Re: Interest in CollectionUtils feature

2024-03-20 Thread Gary D. Gregory
Oops, obviously:

Stream.of(array).filter(e -> !e.isEmpty()).findFirst();

On 2024/03/20 13:18:49 Gary Gregory wrote:
> Hello Marco,
> 
> Good call coming to the mailing list first :-)
> 
> There is a mismatch in concepts in the proposed API IMO.
> 
> But I can't tell for sure since you don't describe the method: there
> are no input, output, and edge case descriptions. I would propose the
> method with what the Javadoc would look like for example.
> 
> Either you want to add a method to ListUtils and pass in a List...,
> or, you want to add a method to CollectionUtils and pass in a
> Collection..., or you want to add a method to IterableUtils and pass
> in an Iterable... The current set of APIs is not perfectly organized
> though.
> 
> Is it more than
> 
> return Stream.of(arrayOfLists).filter(List::isEmpty).findFirst()
> 
> ?
> 
> HTH,
> Gary
> 
> On Wed, Mar 20, 2024 at 7:30 AM Marco Dell'Anna
>  wrote:
> >
> > Hi,
> > I would like to have a CollectionUtils.firstNotEmpty(List... lists) method.
> > Since commons-collections/CONTRIBUTING.md at master ·
> > apache/commons-collections · GitHub
> > 
> > says:
> > * If you're planning to implement a new feature it makes sense to discuss
> > your changes on the dev list first. This way you can make sure you're not
> > wasting your time on something that isn't considered to be in Apache
> > Commons Collections's scope.
> > I'm asking if I should create a Merge Request
> >
> > Thanks
> > Marco Dell'Anna
> 
> -
> 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] EqualsBuilder#reflectionEquals feature brainstorming

2024-03-07 Thread Gary D. Gregory
On 2024/03/07 06:58:30 Mark Struberg wrote:
> The question to me is how we can make it more robust.
> In a Collection (but actually also in most lists) the order in which you get 
> the values (Iterator or get(i)) is not deterministic. It can be different in 
> one list than in another - even if they contain the exact same items.

Hm, so to iterate through Lists in parallel would work but not with Sets.

> 
> Not yet sure how to work around this. We can probably try to sort it first, 
> but then again, if they do not implement Comparable it won't help much. Or do 
> a containsElement based on reflection as well - but that would be rather slow.

This is one of those: If you want support for the feature, it'll work, but 
it'll be slow because there is no other way to do it (for now if ever).

Gary

> 
> Same with Maps. There is a good reason why the key at least should implement 
> equals/hashCode. If this is not the case, then we are not able to implement 
> this properly I fear.
> 
> Any ideas?
> 
> LieGrue,
> strub
> 
> > Am 06.03.2024 um 15:53 schrieb Gary Gregory :
> > 
> > Ah, right, custom "non-equalable" _inside_ Collections and Maps...
> > 
> > For the diff, I'd suggest you test and iterable over a Collection
> > instead of a List.
> > 
> > Then you'd need a separate test and traversal for Map instances.
> > 
> > (Still no common super-interface in Java 21 for Collections and Maps...)
> > 
> > Gary
> > 
> > On Wed, Mar 6, 2024 at 7:40 AM Mark Struberg  
> > wrote:
> >> 
> >> Hi Gregory!
> >> 
> >> I did try this out and figured that I didn't think it though. Maybe I need 
> >> to go a few steps back and explain the problem:
> >> 
> >> I have the following constellation
> >> 
> >> public class SomeInnerDTO {int field..} // NOT implements equals!
> >> public class TheOuterDTO{ List innerList;..}
> >> 
> >> My problem is that reflectionEquals (which I use in a unit test) tries to 
> >> introspect fields even in java.util.classes. And for getting the values of 
> >> those classes it tries to call a setAccessible(true);
> >> And obviously here it fails. There is a ticket already open [1] which 
> >> sugggests to use trySetAccessible. But I fear that will still do nothing 
> >> and you won't get access to those inner knowledge inside 
> >> java.util.LinkedList etc.
> >> 
> >> And using equals() on the List sadly won't help either, as the 
> >> SomeInnerDTO would also get compared with equals(), but that will 
> >> obviously use identity comparison only :(
> >> 
> >> 
> >> What I did for now (running all tests with a few projects right now, but 
> >> looks promising):
> >> 
> >> diff --git 
> >> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java 
> >> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> index ff5276b04..cf878da40 100644
> >> --- a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> +++ b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
> >> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final Object 
> >> lhs, final Object rhs) {
> >> if (bypassReflectionClasses != null
> >> && (bypassReflectionClasses.contains(lhsClass) || 
> >> bypassReflectionClasses.contains(rhsClass))) {
> >> isEquals = lhs.equals(rhs);
> >> +} else if (testClass.isAssignableFrom(List.class)) {
> >> +List lList = (List) lhs;
> >> +List rList = (List) rhs;
> >> +if (lList.size() != rList.size()) {
> >> +isEquals = false;
> >> +return this;
> >> +}
> >> +for (int i = 0; i < lList.size(); i++) {
> >> +reflectionAppend(lList.get(i), rList.get(i));
> >> +}
> >> } else {
> >> 
> >> I'm rather sure this is still not enough and there are plenty other cases 
> >> to consider. Like e.g. handling Maps etc.
> >> But at least that's the direction I try to approach it right now. And of 
> >> course this new part should potentially also be enabled by a flag...
> >> 
> >> Will keep you updated.
> >> 
> >> txs and LieGrue,
> >> strub
> >> 
> >> 
> >> [1] https://issues.apache.org/jira/browse/LANG-1711
> >> 
> >>> Am 06.03.2024 um 13:18 schrieb Gary Gregory :
> >>> 
> >>> This sounds like a good idea to try. I would call the option something 
> >>> else
> >>> though. We would not skip calling equals if it is defined right? How about
> >>> "useEqualsIfPresent".
> >>> 
> >>> Gary
> >>> 
> >>> On Wed, Mar 6, 2024, 5:03 AM Mark Struberg 
> >>> wrote:
> >>> 
>  Hi!
>  
>  I have a question about EqualsBuilder#reflectionEquals. From Java9 
>  onwards
>  we get more and more nasty module problems. Mainly because the code tries
>  to recurse into java.util.* classes as well.
>  I know that I can use setBypassReflectionClasses for those. But wouldn't
>  it be fine to have an additional switch to 

Re: [VOTE] Release Apache Commons BCEL 6.8.2 based on RC1

2024-02-25 Thread Gary D. Gregory
This vote passes with the following +1 binding votes:
- Gary Gregory
- Bruno Kinoshita
- Rob Tompkins

Gary

On 2024/02/24 17:31:30 Rob Tompkins wrote:
> +1
> 
> > On Feb 21, 2024, at 7:18 PM, Gary D. Gregory  wrote:
> > 
> > We have fixed a few bugs since Apache Commons BCEL 6.8.1 was released, so I 
> > would like to release Apache Commons BCEL 6.8.2.
> > 
> > Apache Commons BCEL 6.8.2 RC1 is available for review here:
> >https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1 (svn 
> > revision 67482)
> > 
> > The Git tag commons-bcel-6.8.2-RC1 commit for this RC is 
> > 749d99c14180afb991dca2d02c1ad75fd97f417f which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=749d99c14180afb991dca2d02c1ad75fd97f417f
> > You may checkout this tag using:
> >git clone https://gitbox.apache.org/repos/asf/commons-bcel.git --branch 
> > commons-bcel-6.8.2-RC1 commons-bcel-6.8.2-RC1
> > 
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1691/org/apache/bcel/bcel/6.8.2/
> > 
> > These are the artifacts and their hashes:
> > 
> > #Release SHA-512s
> > #Wed Feb 21 17:43:58 EST 2024
> > bcel-6.8.2-tests.jar=9e4643c904b2187791b1b419e6fd0cc8b75471487c505993f7ebb48f366b21889dac14af01b4a21bd798b16b2f5754bb70e9484a1b2bb096f7a56f83c73706c1
> > bcel-6.8.2-src.zip=9d362d26cb1c52514636c993e3d13f3424ff1aaf5dd897c1ef8d9f7745b069e7ff29d0924261ab1b071d0f11c73baa1052fd780a55d5995e50b3acc49d42f252
> > bcel-6.8.2-javadoc.jar=98ea3681c849e8a2515c111db9360d50d1ed7c0fe0f8257f3536baadbfb2de131c3110ecb1823ea073185cfbc01360d523d5fdfe580511f1efe3456a7e63fcd7
> > bcel-6.8.2-bin.tar.gz=f8ea95821f983be06988f8008c4e402dd48b702547b1d58251b91d544735f8f7370cdda78353c84d7b5932323c1113205fa1e3e9b6235d6dcf2f8e10f3671742
> > bcel-6.8.2-src.tar.gz=17e18323651274bd54c8fc631b27e9460bb7389b3736aac6645da52a6a1ca1d4d5a48b9c987065356bdcd62ddf20f7ec4e563424e3ad504e46495237e254cef6
> > org.apache.bcel_bcel-6.8.2.spdx.json=a2bc9d6da822bc5ec607bf98b26b42f04e663bfd707eb863166052a21f517c0309f25658aded35638219846204385dd37a84eb4fb4f4e21ac6bfed1ddbb484c8
> > bcel-6.8.2-bom.json=65980e4ae082b66c51dd1d774e6d2337a2c6c661c826c4180c1ca948e11feb25b1e9f1707520a555acdb04cd68caede65bf3fc7d8e9628948b862656e0d89d50
> > bcel-6.8.2-bom.xml=8d712f1220bcde65ade4362de1f3a6bb7e66cf8423c83951070bc151ba07c50013dab86fd855b4598dc957458f1c498ac2715758202261f857ce26429563e205
> > bcel-6.8.2-sources.jar=df2ce9772ff98f53b5d00c7ed650a16deb45b573262e2692f91cf34071ad791f126b54706b4ab94385e2fa5deaac81910205668750b304249e119ca7efe7
> > bcel-6.8.2-test-sources.jar=441a271c831da3c73d6dfa6b7fa041ed6c8253528d8ab43ed1fbb9ba88945519ce12dc9b84a38e8b04f869dc37c5f7f5098d5ce0586497eea6b366d67166e054
> > bcel-6.8.2-bin.zip=69a04f10a5e69cea2d6cd54488f0dbe73ed1b46b214cb4e06a9acc7901845a3cd0e89f12d1034b2670ab442eae9957775c61d8fb7a0d7fb77574223deb89468f
> > 
> > I have tested this with:
> > 
> > mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site 
> > deploy
> > 
> > Using:
> > 
> > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> > Maven home: C:\java\apache-maven-3.9.6
> > Java version: 17.0.8, vendor: Eclipse Adoptium, runtime: C:\Program 
> > Files\Eclipse Adoptium\jdk-17.0.8.7-hotspot
> > Default locale: en_US, platform encoding: Cp1252
> > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> > 
> > Microsoft Windows [Version 10.0.19045.3930]
> > 
> > Details of changes since 6.8.1 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1/site/changes-report.html
> > 
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1/site/index.html
> >(note some *relative* links are broken and the 6.8.2 directories are not 
> > yet created - these will be OK once the site is deployed.)
> > 
> > JApiCmp Report (compared to 6.8.1):
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1/site/japicmp.html
> > 
> > RAT Report:
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-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
> >  

Re: [VOTE] Release Apache Commons BCEL 6.8.2 based on RC1

2024-02-23 Thread Gary D. Gregory
My +1

Gary

On 2024/02/22 00:18:35 "Gary D. Gregory" wrote:
> We have fixed a few bugs since Apache Commons BCEL 6.8.1 was released, so I 
> would like to release Apache Commons BCEL 6.8.2.
> 
> Apache Commons BCEL 6.8.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1 (svn 
> revision 67482)
> 
> The Git tag commons-bcel-6.8.2-RC1 commit for this RC is 
> 749d99c14180afb991dca2d02c1ad75fd97f417f which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=749d99c14180afb991dca2d02c1ad75fd97f417f
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-bcel.git --branch 
> commons-bcel-6.8.2-RC1 commons-bcel-6.8.2-RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1691/org/apache/bcel/bcel/6.8.2/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Wed Feb 21 17:43:58 EST 2024
> bcel-6.8.2-tests.jar=9e4643c904b2187791b1b419e6fd0cc8b75471487c505993f7ebb48f366b21889dac14af01b4a21bd798b16b2f5754bb70e9484a1b2bb096f7a56f83c73706c1
> bcel-6.8.2-src.zip=9d362d26cb1c52514636c993e3d13f3424ff1aaf5dd897c1ef8d9f7745b069e7ff29d0924261ab1b071d0f11c73baa1052fd780a55d5995e50b3acc49d42f252
> bcel-6.8.2-javadoc.jar=98ea3681c849e8a2515c111db9360d50d1ed7c0fe0f8257f3536baadbfb2de131c3110ecb1823ea073185cfbc01360d523d5fdfe580511f1efe3456a7e63fcd7
> bcel-6.8.2-bin.tar.gz=f8ea95821f983be06988f8008c4e402dd48b702547b1d58251b91d544735f8f7370cdda78353c84d7b5932323c1113205fa1e3e9b6235d6dcf2f8e10f3671742
> bcel-6.8.2-src.tar.gz=17e18323651274bd54c8fc631b27e9460bb7389b3736aac6645da52a6a1ca1d4d5a48b9c987065356bdcd62ddf20f7ec4e563424e3ad504e46495237e254cef6
> org.apache.bcel_bcel-6.8.2.spdx.json=a2bc9d6da822bc5ec607bf98b26b42f04e663bfd707eb863166052a21f517c0309f25658aded35638219846204385dd37a84eb4fb4f4e21ac6bfed1ddbb484c8
> bcel-6.8.2-bom.json=65980e4ae082b66c51dd1d774e6d2337a2c6c661c826c4180c1ca948e11feb25b1e9f1707520a555acdb04cd68caede65bf3fc7d8e9628948b862656e0d89d50
> bcel-6.8.2-bom.xml=8d712f1220bcde65ade4362de1f3a6bb7e66cf8423c83951070bc151ba07c50013dab86fd855b4598dc957458f1c498ac2715758202261f857ce26429563e205
> bcel-6.8.2-sources.jar=df2ce9772ff98f53b5d00c7ed650a16deb45b573262e2692f91cf34071ad791f126b54706b4ab94385e2fa5deaac81910205668750b304249e119ca7efe7
> bcel-6.8.2-test-sources.jar=441a271c831da3c73d6dfa6b7fa041ed6c8253528d8ab43ed1fbb9ba88945519ce12dc9b84a38e8b04f869dc37c5f7f5098d5ce0586497eea6b366d67166e054
> bcel-6.8.2-bin.zip=69a04f10a5e69cea2d6cd54488f0dbe73ed1b46b214cb4e06a9acc7901845a3cd0e89f12d1034b2670ab442eae9957775c61d8fb7a0d7fb77574223deb89468f
> 
> I have tested this with:
> 
> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
> 
> Using:
> 
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: C:\java\apache-maven-3.9.6
> Java version: 17.0.8, vendor: Eclipse Adoptium, runtime: C:\Program 
> Files\Eclipse Adoptium\jdk-17.0.8.7-hotspot
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Microsoft Windows [Version 10.0.19045.3930]
> 
> Details of changes since 6.8.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1/site/changes-report.html
> 
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1/site/index.html
> (note some *relative* links are broken and the 6.8.2 directories are not 
> yet created - these will be OK once the site is deployed.)
> 
> JApiCmp Report (compared to 6.8.1):
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1/site/japicmp.html
> 
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-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 ch

Re: commons-compress 1.26.0 optional dependency on commons-codec causes runtime failure.

2024-02-23 Thread Gary D. Gregory
On 2024/02/23 12:56:23 Elliotte Rusty Harold wrote:
> On Thu, Feb 22, 2024 at 2:07 PM Romain Manni-Bucau
>  wrote:
> 
> > +1 Elliotte
> > ...plus the fact [io] is optional in the pom too which is not correct.
> 
> Possibly commons-io used to be more legitimately optional, but since a
> lot of things like CountingOutputStream have now moved into commons-io
> it really isn't. Is there anywhere explicit documentation of what
> dependencies commons-compress uses?

Yes, the web site. Each Commons Components web site should have a "Dependency 
Management" page under the "Project Information" section (left hand-side menu).

Gary

> 
> It is really helpful for clients when libraries make a strong effort
> to avoid unnecessary dependencies. I can sort of see that a library
> like compress might depend on lang3 and io, but it would be better if
> it didn't.
> 
> -- 
> Elliotte Rusty Harold
> elh...@ibiblio.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



[VOTE] Release Apache Commons BCEL 6.8.2 based on RC1

2024-02-21 Thread Gary D. Gregory
We have fixed a few bugs since Apache Commons BCEL 6.8.1 was released, so I 
would like to release Apache Commons BCEL 6.8.2.

Apache Commons BCEL 6.8.2 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1 (svn revision 
67482)

The Git tag commons-bcel-6.8.2-RC1 commit for this RC is 
749d99c14180afb991dca2d02c1ad75fd97f417f which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=749d99c14180afb991dca2d02c1ad75fd97f417f
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-bcel.git --branch 
commons-bcel-6.8.2-RC1 commons-bcel-6.8.2-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1691/org/apache/bcel/bcel/6.8.2/

These are the artifacts and their hashes:

#Release SHA-512s
#Wed Feb 21 17:43:58 EST 2024
bcel-6.8.2-tests.jar=9e4643c904b2187791b1b419e6fd0cc8b75471487c505993f7ebb48f366b21889dac14af01b4a21bd798b16b2f5754bb70e9484a1b2bb096f7a56f83c73706c1
bcel-6.8.2-src.zip=9d362d26cb1c52514636c993e3d13f3424ff1aaf5dd897c1ef8d9f7745b069e7ff29d0924261ab1b071d0f11c73baa1052fd780a55d5995e50b3acc49d42f252
bcel-6.8.2-javadoc.jar=98ea3681c849e8a2515c111db9360d50d1ed7c0fe0f8257f3536baadbfb2de131c3110ecb1823ea073185cfbc01360d523d5fdfe580511f1efe3456a7e63fcd7
bcel-6.8.2-bin.tar.gz=f8ea95821f983be06988f8008c4e402dd48b702547b1d58251b91d544735f8f7370cdda78353c84d7b5932323c1113205fa1e3e9b6235d6dcf2f8e10f3671742
bcel-6.8.2-src.tar.gz=17e18323651274bd54c8fc631b27e9460bb7389b3736aac6645da52a6a1ca1d4d5a48b9c987065356bdcd62ddf20f7ec4e563424e3ad504e46495237e254cef6
org.apache.bcel_bcel-6.8.2.spdx.json=a2bc9d6da822bc5ec607bf98b26b42f04e663bfd707eb863166052a21f517c0309f25658aded35638219846204385dd37a84eb4fb4f4e21ac6bfed1ddbb484c8
bcel-6.8.2-bom.json=65980e4ae082b66c51dd1d774e6d2337a2c6c661c826c4180c1ca948e11feb25b1e9f1707520a555acdb04cd68caede65bf3fc7d8e9628948b862656e0d89d50
bcel-6.8.2-bom.xml=8d712f1220bcde65ade4362de1f3a6bb7e66cf8423c83951070bc151ba07c50013dab86fd855b4598dc957458f1c498ac2715758202261f857ce26429563e205
bcel-6.8.2-sources.jar=df2ce9772ff98f53b5d00c7ed650a16deb45b573262e2692f91cf34071ad791f126b54706b4ab94385e2fa5deaac81910205668750b304249e119ca7efe7
bcel-6.8.2-test-sources.jar=441a271c831da3c73d6dfa6b7fa041ed6c8253528d8ab43ed1fbb9ba88945519ce12dc9b84a38e8b04f869dc37c5f7f5098d5ce0586497eea6b366d67166e054
bcel-6.8.2-bin.zip=69a04f10a5e69cea2d6cd54488f0dbe73ed1b46b214cb4e06a9acc7901845a3cd0e89f12d1034b2670ab442eae9957775c61d8fb7a0d7fb77574223deb89468f

I have tested this with:

mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy

Using:

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: C:\java\apache-maven-3.9.6
Java version: 17.0.8, vendor: Eclipse Adoptium, runtime: C:\Program 
Files\Eclipse Adoptium\jdk-17.0.8.7-hotspot
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Microsoft Windows [Version 10.0.19045.3930]

Details of changes since 6.8.1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1/site/index.html
(note some *relative* links are broken and the 6.8.2 directories are not 
yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 6.8.1):

https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-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-bcel.git --branch 
commons-bcel-6.8.2-RC1 commons-bcel-6.8.2-RC1
cd commons-bcel-6.8.2-RC1

1b) Download and unpack the source archive from:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.2-RC1/source

2) Check Apache licenses

This step is not required if the site includes a RAT report page which you then 
must check.

mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page which you 
then must check.

mvn 

Re: [RDF] Bump Java requirement from Java 8 to 11

2024-02-19 Thread Gary D. Gregory
A nice-to-have would be to port from JUnit 4 to 5.

Gary

On 2024/02/20 02:08:03 "Gary D. Gregory" wrote:
> I bumped the Java version, the GitHub CI says Java 11 and 17 are OK but 21 
> and 22-ea are not.
> 
> See https://github.com/apache/commons-rdf/actions/runs/7967484426
> 
> I think we need to address Java 21 before anything else.
> 
> Help wanted ;-)
> 
> Gary
> 
> On 2024/02/19 07:29:49 Bruno Kinoshita wrote:
> > +1
> > 
> > Since the project is created on top of libs like Jena, exactly to provide a
> > common interface go all these libs, I think the simplest is to always go
> > with the minimum thay works with every lib supported.
> > 
> > On Mon, 19 Feb 2024, 08:23 Martijn Verburg, 
> > wrote:
> > 
> > > Let's move the ecosystem forward :-)
> > >
> > > Cheers,
> > > Martijn
> > >
> > >
> > > On Mon, 19 Feb 2024 at 05:07, Gary Gregory  wrote:
> > >
> > > > To use a new Jena version, we would require Java 11.
> > > >
> > > > Raise your hand if this would be a deal breaker for you and why.
> > > >
> > > > Raise your hand to say hi or anything else ;-)
> > > >
> > > > See:
> > > >
> > > > - the thread [RDF] New Jena Version
> > > > - the PR https://github.com/apache/commons-rdf/pull/196
> > > >
> > > > Gary
> > > >
> > > > -
> > > > 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: [RDF] Bump Java requirement from Java 8 to 11

2024-02-19 Thread Gary D. Gregory
PRs will have to be rebased obviously.

Gary

On 2024/02/20 02:08:03 "Gary D. Gregory" wrote:
> I bumped the Java version, the GitHub CI says Java 11 and 17 are OK but 21 
> and 22-ea are not.
> 
> See https://github.com/apache/commons-rdf/actions/runs/7967484426
> 
> I think we need to address Java 21 before anything else.
> 
> Help wanted ;-)
> 
> Gary
> 
> On 2024/02/19 07:29:49 Bruno Kinoshita wrote:
> > +1
> > 
> > Since the project is created on top of libs like Jena, exactly to provide a
> > common interface go all these libs, I think the simplest is to always go
> > with the minimum thay works with every lib supported.
> > 
> > On Mon, 19 Feb 2024, 08:23 Martijn Verburg, 
> > wrote:
> > 
> > > Let's move the ecosystem forward :-)
> > >
> > > Cheers,
> > > Martijn
> > >
> > >
> > > On Mon, 19 Feb 2024 at 05:07, Gary Gregory  wrote:
> > >
> > > > To use a new Jena version, we would require Java 11.
> > > >
> > > > Raise your hand if this would be a deal breaker for you and why.
> > > >
> > > > Raise your hand to say hi or anything else ;-)
> > > >
> > > > See:
> > > >
> > > > - the thread [RDF] New Jena Version
> > > > - the PR https://github.com/apache/commons-rdf/pull/196
> > > >
> > > > Gary
> > > >
> > > > -
> > > > 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: [RDF] Bump Java requirement from Java 8 to 11

2024-02-19 Thread Gary D. Gregory
I bumped the Java version, the GitHub CI says Java 11 and 17 are OK but 21 and 
22-ea are not.

See https://github.com/apache/commons-rdf/actions/runs/7967484426

I think we need to address Java 21 before anything else.

Help wanted ;-)

Gary

On 2024/02/19 07:29:49 Bruno Kinoshita wrote:
> +1
> 
> Since the project is created on top of libs like Jena, exactly to provide a
> common interface go all these libs, I think the simplest is to always go
> with the minimum thay works with every lib supported.
> 
> On Mon, 19 Feb 2024, 08:23 Martijn Verburg, 
> wrote:
> 
> > Let's move the ecosystem forward :-)
> >
> > Cheers,
> > Martijn
> >
> >
> > On Mon, 19 Feb 2024 at 05:07, Gary Gregory  wrote:
> >
> > > To use a new Jena version, we would require Java 11.
> > >
> > > Raise your hand if this would be a deal breaker for you and why.
> > >
> > > Raise your hand to say hi or anything else ;-)
> > >
> > > See:
> > >
> > > - the thread [RDF] New Jena Version
> > > - the PR https://github.com/apache/commons-rdf/pull/196
> > >
> > > Gary
> > >
> > > -
> > > 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 Codec 1.16.1 based on RC1

2024-02-08 Thread Gary D. Gregory
My +1

Gary

On 2024/02/06 18:48:12 Rob Tompkins wrote:
> +1 all looks good.
> 
> Keep up the good work Gary!!!
> 
> Cheers,
> -Rob
> 
> > On Feb 4, 2024, at 10:40 AM, Gary Gregory  wrote:
> > 
> > We have fixed a few bugs and added some enhancements since Apache
> > Commons Codec 1.16.0 was released, so I would like to release Apache
> > Commons Codec 1.16.1.
> > 
> > Apache Commons Codec 1.16.1 RC1 is available for review here:
> >https://dist.apache.org/repos/dist/dev/commons/codec/1.16.1-RC1
> > (svn revision 67174)
> > 
> > The Git tag commons-codec-1.16.1-RC1 commit for this RC is
> > e59fc76531141cb4a36f3031457b9d5f07e5e43f which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=e59fc76531141cb4a36f3031457b9d5f07e5e43f
> > You may checkout this tag using:
> >git clone https://gitbox.apache.org/repos/asf/commons-codec.git
> > --branch commons-codec-1.16.1-RC1 commons-codec-1.16.1-RC1
> > 
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1688/commons-codec/commons-codec/1.16.1/
> > 
> > These are the artifacts and their hashes:
> > 
> > #Release SHA-512s
> > #Sun Feb 04 15:31:03 UTC 2024
> > commons-codec-1.16.1-bin.tar.gz=b9088ca7bd63cfe56c06c855af809948cae730b2be5c4c02619cf9a5cea2fab5c2226a3bec60d4f638dcd9af13700bb4e9f27fa1fac74d9249fae45042cb2a2a
> > commons-codec-1.16.1-bin.zip=81e87157533219e0162e5a2218ed891dbe5310729c8fe0f7208da5f1dc8f058ddb46990b3d8cdace2984a37043d1d6a0648e8c2d04e78831e1beb8b1d58ae130
> > commons-codec-1.16.1-bom.json=ccd6aadad4bd4ec67651eddff31fbb0c9568701bcc6a952e32929dc24c393d0b84a2f45e229eaf6f7b996dedf30524aaed25a359be49e85dedd6430219b8a1c3
> > commons-codec-1.16.1-bom.xml=958dff0d9be2ac855bace9976903a5e289fe65b10a797006a962151c2f15516d5b0a3eb46f441f76ded49fea46581e7b07baa42912a9da583c385d6b9f5c849b
> > commons-codec-1.16.1-javadoc.jar=027e85f4fe8adb2914e0b6bb80139081985e64097155f5f58f7c4141defc43a51d22da398c1cde1ac2ec18c6014c760e12bcfc40f48209bcb937a08249bff487
> > commons-codec-1.16.1-sources.jar=434725ec624f3e60a0bb174f1d505e0aeb10d2255035d3ecc215248e3336fae0cee08374604a989c4c09458c772830342908ebcc269a232569b1d780f2dba04e
> > commons-codec-1.16.1-src.tar.gz=8e2d40ae625c04e61b0dd7473dea0b32fdd13a6d3aad47b8b052952ca46f57d3df4917133f523ea147305a1c7ed9267cce7c4fa34d901496e36e9d5de9856e61
> > commons-codec-1.16.1-src.zip=c2f5a26959c33c43c71df7eebfddf7c1a255a19faa8dd0324c19cfa902f9a4d3876689deffb99cf68456785b8960705b0a2b62e567c83b0ce674f26ef6db2eea
> > commons-codec-1.16.1-test-sources.jar=1619f6d6dec4c4c0a26cb278cf53dffac2fb137d0c1f684156f19ef5db3a64ce2554dab29dc19a44247bf56d9bd3685c8c6d30234d15bd8cada28a12d35b47c4
> > commons-codec-1.16.1-tests.jar=3e5496a79bc29558369cc356d3a2f8f0b2116fe8ae0c0ca2e3033988f47afd6b7ad1bbf8d3dabfda558b8912d4f77c40a67617237a8ddd70fe738e5c76e895e2
> > commons-codec_commons-codec-1.16.1.spdx.json=a306898741d0fc70d9d773bc6ca88236c6d03bbce239d409c697ee516c1ff258c617599852dfdaa0cc80125e97fd555d2c9e1457f1adb43f863af88c9cd11bda
> > 
> > 
> > I have tested this with:
> > 
> > mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site 
> > deploy
> > 
> > using:
> > 
> > openjdk version "17.0.9" 2023-10-17
> > OpenJDK Runtime Environment Homebrew (build 17.0.9+0)
> > OpenJDK 64-Bit Server VM Homebrew (build 17.0.9+0, mixed mode, sharing)
> > 
> > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> > Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> > Java version: 17.0.9, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@17/17.0.9/libexec/openjdk.jdk/Contents/Home
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "14.3", arch: "x86_64", family: "mac"
> > 
> > Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
> > PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64
> > 
> > Details of changes since 1.16.0 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/codec/1.16.1-RC1/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/codec/1.16.1-RC1/site/changes-report.html
> > 
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/codec/1.16.1-RC1/site/index.html
> >(note some *relative* links are broken and the 1.16.1 directories
> > are not yet created - these will be OK once the site is deployed.)
> > 
> > JApiCmp Report (compared to 1.16.0):
> >
> > https://dist.apache.org/repos/dist/dev/commons/codec/1.16.1-RC1/site/japicmp.html
> > 
> > RAT Report:
> >
> > https://dist.apache.org/repos/dist/dev/commons/codec/1.16.1-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...
> > 
> > 

[COMPRESS] Decompress BZIP2 File Max Output is 900000 chars

2024-01-31 Thread Gary D. Gregory
Hi All,

If anyone is looking for an issue to investigate:

[COMPRESS-651] Decompress BZIP2 File Max Output is 90 chars
https://issues.apache.org/jira/browse/COMPRESS-651

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: Security model for Commons Imaging, Compress, Codec and IO: RCE and DOS?

2023-12-14 Thread Gary D. Gregory
Thank you Arnout for starting this thread.

I think it's going to be hard to come up with a sensible statement for all 20+ 
Commons components without categorizing them (some higher/lower level 
classification) even though this thread only refers to four components. 

We can make some general statements: For my $, we should deprecate all 
serialization and deserialization, and remove that support in next major 
versions, for all components. This is the simplest solution. We can recommend 
using serialization proxies a la Effective Java (Bloch). In practical terms, 
this means no longer implementing Serializable and not deserializing anything.

For RCEs and us calling APIs like Runtime#exec(...), it's not so simple, 
because we have some components that are in effect languages (JEXL for 
example), so there we can start with saying you must sanitize your inputs, 
which is "hard" to saying we'll provide allow and/or deny lists in the future.

For memory and CPU consumption issues, we want to avoid zip-bomb issues, and 
that's where code inspections and fuzzing will help and has already helped. 
Commons Imaging and Compress are two obvious targets here. It's going to take 
some rework of internals to allow for call sites to say something like: 
"process this blob but only use a max of 10 MB".

Gary

On 2023/12/14 11:09:18 Arnout Engelen wrote:
> Hello Commons developers,
> 
> I'd like to discuss what our security ambitions are for components like
> Commons Imaging, Compress, Codec and IO:
> 
> Generally for Commons, we say that unless otherwise specified it is up to
> the user of the library to make sure any input is either trusted or
> correctly validated/sanitized (https://commons.apache.org/security.html).
> 
> For these modules it might make sense to be a little more nuanced:
> https://commons.apache.org/proper/commons-imaging/ already explicitly says
> it intends to be "more secure against corrupt/malicious images", and while
> the others don't seem to say it explicitly AFAICS in practice we consider
> it OK to decompress/decode/... untrusted input at least to some degree.
> 
> So what does that mean?
> 
> * I'd say parsing/decompression/decoding should never allow malicious input
> to trigger arbitrary code execution(?)
> * Should parsing/decompression/decoding protect against 'disproportionate'
> CPU usage?
> * Should parsing/decompression/decoding protect against 'disproportionate'
> memory usage?
> * Should parsing/decompression/decoding protect against 'disproportionate'
> disk usage?
> 
> Where we say 'yes', we should also decide whether we intend to treat such
> issues as security problems (that should be fixed with some priority and,
> after release, disclosed in an advisory) or bugs/improvements (where we can
> possibly take more of an 'issues and patches welcome' position).
> 
> I'm curious about your thoughts!
> 
> 
> -- 
> Arnout Engelen
> ASF Security Response
> Committer on Apache Pekko
> Committer on NixOS
> Independent Open Source consultant
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



[COMPRESS] Optimize the nameMap of ZipFile #378

2023-11-28 Thread Gary D. Gregory
Hi All,

I'd like community feedback on whether it is OK to merge 
https://github.com/apache/commons-compress/pull/378

TY!
Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [VALIDATOR] - Release of newer version of validator without OWASP vulnerabilities

2023-11-28 Thread Gary D. Gregory
Henrique,

I should also ask: If you look at git master, is there anything you see that 
needs updating?

TY!
Gary

On 2023/11/23 02:31:26 Henrique Siqueira Santos wrote:
> I was wondering how the updates for some of the apache commons libraries work 
> in regards to the vulnerabilities of dependencies of a library (in this case, 
> commons-validator).
> 
> Is it possible to create a pull request with only upgrades of dependencies of 
> a library? For instance, in the commons-validator library, there are some 
> dependencies which contains vulnerabilities such as jUnit. Is a pull request 
> to upgrade jUnit from 4.13 to 4.13.2 valid?
> 
> Another different example would be the commons-digester library which, from 
> what I've seen, has the 3.3-SNAPSHOT version on it's master branch which 
> contains some upgrades to those vulnerable dependencies, but it hasn't been 
> released yet.
> 
> Is there a release cycle or release date planned for these changes?
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [lang] RandomStringUtilsTest.testRandomStringUtilsHomog fails a lot

2023-10-20 Thread Gary D. Gregory
Hi Alex,

I'd prefer if you could give a shot at adjusting this test when you can take 
the time.

TY,
Gary

On 2023/10/20 18:17:35 Alex Herbert wrote:
> On Fri, 20 Oct 2023 at 18:55, Alex Herbert  wrote:
> >
> > The chi-square critical value (13.82) is correct:
> >
> > >>> from scipy.stats import chi2
> > >>> chi2(2).isf(0.001)
> > 13.815510557964274
> >
> > The test seems to fail with the expected frequency when run locally. I
> > annotated with:
> >
> > @RepeatedTest(value = 10)
> >
> > I observe 93 failures (just under 1 in 1000). So it is strange this
> > fails a lot on the GH CI build.
> >
> > We could just use a fixed Random argument to the call that is
> > ultimately performing the random string generation:
> >
> > random(count, 0, chars.length, false, false, chars, random());
> >
> > Switch the test to:
> >
> > Random rng = new Random(0xdeadbeef)
> >
> > gen = RandomStringUtils.random(6, 0, 3, false, false, chars, rng);
> >
> > You will see a drop in coverage by not exercising the public API.
> >
> > The alternative is to change the chi-square critical value:
> >
> > 1 in 10,000: 18.420680743952364
> > 1 in 100,000: 23.025850929940457
> > 1 in 1,000,000: 27.631021115928547
> >
> > Alex
> 
> Also note that although the test fails 1 in 1000 times, we run 4
> builds in CI (coverage + 3 JDKS). So we expect to see failure with a
> p-value of:
> 
> 1 - (1 - 0.001)^4 = 0.00399
> 
> This is the probability of not seeing a failure subtracted from 1. It
> is approximately 1 in 250.
> 
> I did check the computation of the chi-square statistic and AFAIK it is 
> correct.
> 
> My suggestion for a first change is to bump the critical value to the
> level for 1 in 100,000. We should then see failures every 25,000 GH
> builds. If the frequency is more than that then we have to assume that
> the ThreadLocalRandom instance is not uniformly sampling from the set
> of size 3. I find this unlikely as the underlying algorithm for
> ThreadLocalRandom is good [1].
> 
> Alex
> 
> [1] IIRC it passes the Test U01 BigCrush test for random generators
> 
> -
> 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



[lang] RandomStringUtilsTest.testRandomStringUtilsHomog fails a lot

2023-10-20 Thread Gary D. Gregory
Despite the failure comment:

RandomStringUtilsTest.testRandomStringUtilsHomog:474 test homogeneity -- will 
fail about 1 in 1000 times ==> expected:  but was: 

This test fails a LOT more than once every 1000 times, based on how many GitHub 
builds I need to restart every week.

What can be done to make this test more resilient?

TY!
Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



[BeanUtils] Java 21 failure converting time and timestamps

2023-10-20 Thread Gary D. Gregory
It seems that on top of our double trouble with [text], we have run into 
another conversion issue with Java 21, this time in [BeanUtils].

I'd like help figuring this one out:

Error:  
org.apache.commons.beanutils2.sql.converters.SqlTimeConverterTestCase.testLocale
 -- Time elapsed: 0.009 s <<< FAILURE!
junit.framework.AssertionFailedError: Converting 'java.lang.String' value '3:06 
pm' threw org.apache.commons.beanutils2.ConversionException: Error converting 
'String' to 'java.sql.Time' using pattern 'h:mm a', localized pattern 'h:mm a', 
errorIndex 4, calendar type GregorianCalendar, this 
org.apache.commons.beanutils2.sql.converters.SqlTimeConverter[UseDefault=false, 
UseLocaleFormat=true]
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:223)
at 
org.apache.commons.beanutils2.converters.AbstractDateConverterTest.validConversion(AbstractDateConverterTest.java:572)
at 
org.apache.commons.beanutils2.sql.converters.SqlTimeConverterTestCase.testLocale(SqlTimeConverterTestCase.java:118)

[INFO] Running 
org.apache.commons.beanutils2.sql.converters.SqlTimestampConverterTestCase
Error:  Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016 
s <<< FAILURE! -- in 
org.apache.commons.beanutils2.sql.converters.SqlTimestampConverterTestCase
Error:  
org.apache.commons.beanutils2.sql.converters.SqlTimestampConverterTestCase.testLocale
 -- Time elapsed: 0.010 s <<< FAILURE!
junit.framework.AssertionFailedError: Converting 'java.lang.String' value 
'3/21/06, 3:06 PM' threw org.apache.commons.beanutils2.ConversionException: 
Error converting 'String' to 'java.sql.Timestamp' using pattern 'M/d/yy, h:mm 
a', localized pattern 'M/d/yy, h:mm a', errorIndex 13, calendar type 
GregorianCalendar, this 
org.apache.commons.beanutils2.sql.converters.SqlTimestampConverter[UseDefault=false,
 UseLocaleFormat=true]
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:223)
at 
org.apache.commons.beanutils2.converters.AbstractDateConverterTest.validConversion(AbstractDateConverterTest.java:572)
at 
org.apache.commons.beanutils2.sql.converters.SqlTimestampConverterTestCase.testLocale(SqlTimestampConverterTestCase.java:138)

TY!
Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



CVE-2023-42503: Apache Commons Compress: Denial of service via CPU consumption for malformed TAR file

2023-09-13 Thread Gary D. Gregory
Severity: moderate

Affected versions:

- Apache Commons Compress 1.22 before 1.24.0

Description:

Improper Input Validation, Uncontrolled Resource Consumption vulnerability in 
Apache Commons Compress in TAR parsing.This issue affects Apache Commons 
Compress: from 1.22 before 1.24.0.

Users are recommended to upgrade to version 1.24.0, which fixes the issue.

A third party can create a malformed TAR file by manipulating file modification 
times headers, which when parsed with Apache Commons Compress, will cause a 
denial of service issue via CPU consumption.

In version 1.22 of Apache Commons Compress, support was added for file 
modification times with higher precision (issue # COMPRESS-612 [1]). The format 
for the PAX extended headers carrying this data consists of two numbers 
separated by a period [2], indicating seconds and subsecond precision (for 
example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, 
“mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior 
to the parsing of header values.

Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a 
publicly known algorithmic complexity issue when doing operations on large 
numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party 
can manipulate file time headers in a TAR file by placing a number with a very 
long fraction (300,000 digits) or a number with exponent notation (such as 
“9e999”) within a file modification time header, and the parsing of files 
with these headers will take hours instead of seconds, leading to a denial of 
service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 
[5].

[1]:  https://issues.apache.org/jira/browse/COMPRESS-612 
[2]:  
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05
 
[3]:  https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html 
[4]:  https://bugs.openjdk.org/browse/JDK-6560193 
[5]:  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 

Only applications using CompressorStreamFactory class (with auto-detection of 
file types), TarArchiveInputStream and TarFile classes to parse TAR files are 
impacted. Since this code was introduced in v1.22, only that version and later 
versions are impacted.

Credit:

Yakov Shafranovich, Amazon Web Services (reporter)

References:

https://commons.apache.org/
https://www.cve.org/CVERecord?id=CVE-2023-42503


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [Codec] clearing input byte array vs not

2023-08-09 Thread Gary D. Gregory
Done and done in git master.

Next, is how to document or change 
org.apache.commons.codec.digest.Crypt.crypt(byte[], String): The method clears 
the input byte array for all input types _except_ when calling UnixCrypt [1].

I could: 
(1) Document the inconsistency (right now, I left it unsaid)
(2) Make UnixCrypt.crypt() clear its input password for consistency.

WDYT?

TY!
Gary
[1]:
   public static String crypt(final byte[] keyBytes, final String salt) {
if (salt == null) {
return Sha2Crypt.sha512Crypt(keyBytes);
}
if (salt.startsWith(Sha2Crypt.SHA512_PREFIX)) {
return Sha2Crypt.sha512Crypt(keyBytes, salt);
}
if (salt.startsWith(Sha2Crypt.SHA256_PREFIX)) {
return Sha2Crypt.sha256Crypt(keyBytes, salt);
}
if (salt.startsWith(Md5Crypt.MD5_PREFIX)) {
return Md5Crypt.md5Crypt(keyBytes, salt);
}
return UnixCrypt.crypt(keyBytes, salt);
}


On 2023/08/09 19:16:59 Mark Thomas wrote:
> Reject it. And document the existing behavior.
> 
> Mark
> 
> 
> On 09/08/2023 19:52, Gary Gregory wrote:
> > Hi all,
> > 
> > Any thoughts on https://github.com/apache/commons-codec/pull/197
> > 
> > Gary
> > 
> 
> -
> 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



[IMAGING] Logging vs Throwing exceptions

2023-05-09 Thread Gary D. Gregory
Hi All,

The method 
org.apache.commons.imaging.icc.IccProfileParser.getICCProfileInfo(ByteSource) 
looks like:

public IccProfileInfo getICCProfileInfo(final ByteSource byteSource) {
// TODO Throw instead of logging?
final IccProfileInfo result;
try (InputStream is = byteSource.getInputStream()) {
result = readICCProfileInfo(is);
} catch (final Exception e) {
LOGGER.log(Level.SEVERE, e.getMessage(), e);
return null;
}
//
try {
for (final IccTag tag : result.getTags()) {
final byte[] bytes = byteSource.getBlock(tag.offset, 
tag.length);
// Debug.debug("bytes: " + bytes.length);
tag.setData(bytes);
// tag.dump("\t" + i + ": ");
}
// result.fillInTagData(byteSource);
return result;
} catch (final Exception e) {
// Debug.debug("Error: " + file.getAbsolutePath());
LOGGER.log(Level.SEVERE, e.getMessage(), e);
}
return null;
}

I find it odd and dubious that we would short-circuit the propagation of 
exceptions with logging in such a low-level code. Unless someone can argue 
otherwise, I would like to propagate the exceptions.

TY,
Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [VOTE] Release Apache Commons Daemon 1.3.4 based on RC1

2023-05-06 Thread Gary D. Gregory
FYI I seem to be building fine for me using "Microsoft (R) C/C++ Optimizing 
Compiler Version 19.35.32217.1 for x64" but maybe there is a gotcha I am 
missing?

Gary

On 2023/05/06 15:12:56 "Gary D. Gregory" wrote:
> Note a blocker but I imagine not true for this release: In the README.txt for 
> the Windows native apps:
> 
> "Release builds are build with Mladen Turk's (mturk) Custom Microsoft Compiler
> Toolkit Compilation. This can be obtained from:
> https://github.com/mturk/cmsc
> Version: 15.0.44"
> 
> Is this true for this release?
> 
> Gary
> 
> 
> On 2023/05/05 10:27:23 Mark Thomas wrote:
> > We have fixed a few bugs since Apache Commons Daemon 1.3.3 was released, 
> > so I would like to release Apache Commons Daemon 1.3.4.
> > 
> > Apache Commons Daemon 1.3.4 RC1 is available for review here:
> >  https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.4-RC1 
> > (svn revision 61662)
> > 
> > The Git tag commons-daemon-1.3.4-RC1 commit for this RC is 
> > f7c21ce501eee288c488edd416f0ddccdd365966 which you can browse here:
> > 
> > https://github.com/apache/commons-daemon/commit/f7c21ce501eee288c488edd416f0ddccdd365966
> > 
> > (gitbox browsing is currently disabled)
> > 
> > You may checkout this tag using:
> >  git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
> > --branch commons-daemon-1.3.4-RC1 commons-daemon-1.3.4-RC1
> > 
> > Maven artifacts are here:
> >  
> > https://repository.apache.org/content/repositories/orgapachecommons-1634/commons-daemon/commons-daemon/1.3.4/
> > 
> > These are the artifacts and their hashes:
> > 
> > commons-daemon-1.3.4.jar=31e723efc879fb1a45001bcb1577c02defe38b0a7e02fc4efd2800f85a4dbe583eba2e67323145aa5c2c5cf9dd09c457961557898a9923e85b0375c73c639498
> > commons-daemon-1.3.4-bin.tar.gz=adc301fe9c7e50c5ed71c6775c8c41c33a369a05c30785ccb81209089603ae66563e958b466c99fc5cd27c12625bb7def68d7d91933aa8739eb645af37f3d03e
> > commons-daemon-1.3.4-bin.zip=857da3217d9186b034ffecf36b8d0df84b3b4de8b06a81338df97dbabafeff9b84034d49173623f5b03786d48d85d406af8e602ea644c95552f2df68f98d5ddc
> > commons-daemon-1.3.4-bin-windows.zip=57a59d402dd0a1c99ed5da062b4616d54679e4208abec8b25742f5bf3ec1ee6b5187bc830edeaa218766215371b5519ce0a7186325c929c86b567a3078aa7555
> > commons-daemon-1.3.4-native-src.tar.gz=3c10ca72fc0eb7f755c0b5452bb6d5e8b42d8f363767ffcd9a6f0883026e688ea7dff50ea05e2675a7cdf9f413cb8012ee6b79e16dfc1cd4d83bd775ea10216c
> > commons-daemon-1.3.4-native-src.zip=2e2db21b142b40427c43f4802ec94fb6212d1c79cb6aa02325b71017e20384a8d6123148603eda03f309aeae5a6f88f9a014deb978af0fac2f62b576d73ae1b8
> > commons-daemon-1.3.4-src.tar.gz=bb36d88bc21a5777245012b2a73ee0e764b85715731f54cc4ff09343e95ccb18fc6c68b3ae9c680fb45a60c7ef5ed0f9e40991c2c03246dd7f8dd65031eddf24
> > commons-daemon-1.3.4-src.zip=2f77720724069655828cecb639a3c9a8411e97ed4c9923340f521cf7078ce85e5d223f20431040411a592b4d38208144ffc56da8b70091f75028a1aad9c51891
> > 
> > 
> > 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,
> > 
> > Mark Thomas,
> > Release Manager (using key 10C01C5A2F6059E7)
> > 
> > -
> > 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: [VOTE] Release Apache Commons Daemon 1.3.4 based on RC1

2023-05-06 Thread Gary D. Gregory
Note a blocker but I imagine not true for this release: In the README.txt for 
the Windows native apps:

"Release builds are build with Mladen Turk's (mturk) Custom Microsoft Compiler
Toolkit Compilation. This can be obtained from:
https://github.com/mturk/cmsc
Version: 15.0.44"

Is this true for this release?

Gary


On 2023/05/05 10:27:23 Mark Thomas wrote:
> We have fixed a few bugs since Apache Commons Daemon 1.3.3 was released, 
> so I would like to release Apache Commons Daemon 1.3.4.
> 
> Apache Commons Daemon 1.3.4 RC1 is available for review here:
>  https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.4-RC1 
> (svn revision 61662)
> 
> The Git tag commons-daemon-1.3.4-RC1 commit for this RC is 
> f7c21ce501eee288c488edd416f0ddccdd365966 which you can browse here:
> 
> https://github.com/apache/commons-daemon/commit/f7c21ce501eee288c488edd416f0ddccdd365966
> 
> (gitbox browsing is currently disabled)
> 
> You may checkout this tag using:
>  git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
> --branch commons-daemon-1.3.4-RC1 commons-daemon-1.3.4-RC1
> 
> Maven artifacts are here:
>  
> https://repository.apache.org/content/repositories/orgapachecommons-1634/commons-daemon/commons-daemon/1.3.4/
> 
> These are the artifacts and their hashes:
> 
> commons-daemon-1.3.4.jar=31e723efc879fb1a45001bcb1577c02defe38b0a7e02fc4efd2800f85a4dbe583eba2e67323145aa5c2c5cf9dd09c457961557898a9923e85b0375c73c639498
> commons-daemon-1.3.4-bin.tar.gz=adc301fe9c7e50c5ed71c6775c8c41c33a369a05c30785ccb81209089603ae66563e958b466c99fc5cd27c12625bb7def68d7d91933aa8739eb645af37f3d03e
> commons-daemon-1.3.4-bin.zip=857da3217d9186b034ffecf36b8d0df84b3b4de8b06a81338df97dbabafeff9b84034d49173623f5b03786d48d85d406af8e602ea644c95552f2df68f98d5ddc
> commons-daemon-1.3.4-bin-windows.zip=57a59d402dd0a1c99ed5da062b4616d54679e4208abec8b25742f5bf3ec1ee6b5187bc830edeaa218766215371b5519ce0a7186325c929c86b567a3078aa7555
> commons-daemon-1.3.4-native-src.tar.gz=3c10ca72fc0eb7f755c0b5452bb6d5e8b42d8f363767ffcd9a6f0883026e688ea7dff50ea05e2675a7cdf9f413cb8012ee6b79e16dfc1cd4d83bd775ea10216c
> commons-daemon-1.3.4-native-src.zip=2e2db21b142b40427c43f4802ec94fb6212d1c79cb6aa02325b71017e20384a8d6123148603eda03f309aeae5a6f88f9a014deb978af0fac2f62b576d73ae1b8
> commons-daemon-1.3.4-src.tar.gz=bb36d88bc21a5777245012b2a73ee0e764b85715731f54cc4ff09343e95ccb18fc6c68b3ae9c680fb45a60c7ef5ed0f9e40991c2c03246dd7f8dd65031eddf24
> commons-daemon-1.3.4-src.zip=2f77720724069655828cecb639a3c9a8411e97ed4c9923340f521cf7078ce85e5d223f20431040411a592b4d38208144ffc56da8b70091f75028a1aad9c51891
> 
> 
> 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,
> 
> Mark Thomas,
> Release Manager (using key 10C01C5A2F6059E7)
> 
> -
> 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 IO 2.12.0 based on RC1

2023-05-03 Thread Gary D. Gregory
ay be a
> reason that blocks use of the API that I did not notice (as I did not
> try to implement it).

These classes now use builders.

> 
> NullOutputStream deprecated constructor references deprecated
> NULL_OUTPUT_STREAM singleton. Should be INSTANCE. 

Done.

 >Following on from
> this should the NullPrintStream and NullWriter constructors also be
> deprecated in favour of the INSTANCE?

Yes, done and done.

> 
> New class UncheckedFilterOutputStream has a public constructor but
> UncheckedFilterWriter is protected. Both have a static 'on' method for
> construction so this is inconsistent. These could use the
> AbstractStreamBuilder API although the constructors are very simple.
> Use of the new API would allow use of Path/File as output.

Done.

> 
> New class ThreadUtils has a TODO in the javadoc. The javadoc also
> requires  tags. The TODO can be moved to a method comment rather
> than being within the javadoc where I do not think it is beneficial to
> the end-user.

Done. I've also made the class final.

> 
> I do not think these are blockers. Extra docs on the use of the
> builders can be added later. But it may be nice to clean up little
> inconsistencies in the new public before release.

I agree that none of these are likely blockers on their own but taken together 
the code base can be made significantly better.

What put it over the edge for me is that new code that did not use builders 
should, and implementing this later would then cause deprecation of code we 
just introduced.

TY!
Gary

> 
> Alex
> 
> [1] 
> https://pmd.github.io/pmd/pmd_rules_java_design.html#classwithonlyprivateconstructorsshouldbefinal
> [2] https://maven.apache.org/plugins/maven-pmd-plugin/pmd-mojo.html#rulesets
> 
> On Tue, 2 May 2023 at 12:44, Gary Gregory  wrote:
> >
> > Ping PMC (and others welcome).
> >
> > Gary
> >
> >
> > On Mon, May 1, 2023, 08:47 Gary D. Gregory  wrote:
> >
> > > Get we get more reviews, please?
> > >
> > > TY!
> > > Gary
> > >
> > > On 2023/04/29 22:01:52 Bruno Kinoshita wrote:
> > > > +1
> > > >
> > > > Build from tag passed with no errors on
> > > >
> > > > Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> > > > Maven home: /opt/apache-maven-3.8.5
> > > > Java version: 17.0.6, vendor: Private Build, runtime:
> > > > /usr/lib/jvm/java-17-openjdk-amd64
> > > > Default locale: en_US, platform encoding: UTF-8
> > > > OS name: "linux", version: "5.15.0-70-generic", arch: "amd64", family:
> > > > "unix"
> > > >
> > > > Site reports look good. On my laptop it didn't create the spotbugs and
> > > > checkstyle reports with `mvn site`. But looking at the dist area site
> > > > everything looks good.
> > > >
> > > > Thanks!
> > > >
> > > > Bruno
> > > >
> > > >
> > > > On Sat, 29 Apr 2023 at 02:33, Gary Gregory 
> > > wrote:
> > > >
> > > > > We have fixed quite a few bugs and added some significant enhancements
> > > > > since Apache Commons IO 2.11.0 was released, so I would like to
> > > > > release Apache Commons IO 2.12.0.
> > > > >
> > > > > Apache Commons IO 2.12.0 RC1 is available for review here:
> > > > > https://dist.apache.org/repos/dist/dev/commons/io/2.12.0-RC1 (svn
> > > > > revision 61539)
> > > > >
> > > > > The Git tag commons-io-2.12.0-RC1 commit for this RC is
> > > > > c780ef616bd6c7340f1d8a5dc8c209376a76451f which you can browse here:
> > > > >
> > > > >
> > > https://gitbox.apache.org/repos/asf?p=commons-io.git;a=commit;h=c780ef616bd6c7340f1d8a5dc8c209376a76451f
> > > > > You may checkout this tag using:
> > > > > git clone https://gitbox.apache.org/repos/asf/commons-io.git
> > > > > --branch commons-io-2.12.0-RC1 commons-io-2.12.0-RC1
> > > > >
> > > > > Maven artifacts are here:
> > > > >
> > > > >
> > > https://repository.apache.org/content/repositories/orgapachecommons-1633/commons-io/commons-io/2.12.0/
> > > > >
> > > > > These are the artifacts and their hashes:
> > > > >
> > > > > #Release SHA-512s
> > > > > #Fri Apr 28 17:58:50 EDT 2023
> > > > >
> > > > >
> > > commons-io-2.12.0-bin.tar.gz=f291190a52b594300ba5df32ae2698378b56f999c

[IO] Deprecating Serialization

2023-05-02 Thread Gary D. Gregory
As we did for Apache Commons CVS, I plan on deprecating Serialization in Apache 
Commons IO for the usual "Item 85" [1] reasons focusing on security.

I will add the following comment to classes that implement Serializable:

 * Deprecating Serialization
 * 
 * Serialization is deprecated and will be removed in 3.0.
 * 

Gary
[1] https://ahdak.github.io/blog/effective-java-part-11/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [VOTE] Release Apache Commons IO 2.12.0 based on RC1

2023-05-01 Thread Gary D. Gregory
Get we get more reviews, please?

TY!
Gary

On 2023/04/29 22:01:52 Bruno Kinoshita wrote:
> +1
> 
> Build from tag passed with no errors on
> 
> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> Maven home: /opt/apache-maven-3.8.5
> Java version: 17.0.6, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-70-generic", arch: "amd64", family:
> "unix"
> 
> Site reports look good. On my laptop it didn't create the spotbugs and
> checkstyle reports with `mvn site`. But looking at the dist area site
> everything looks good.
> 
> Thanks!
> 
> Bruno
> 
> 
> On Sat, 29 Apr 2023 at 02:33, Gary Gregory  wrote:
> 
> > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Commons IO 2.11.0 was released, so I would like to
> > release Apache Commons IO 2.12.0.
> >
> > Apache Commons IO 2.12.0 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/io/2.12.0-RC1 (svn
> > revision 61539)
> >
> > The Git tag commons-io-2.12.0-RC1 commit for this RC is
> > c780ef616bd6c7340f1d8a5dc8c209376a76451f which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-io.git;a=commit;h=c780ef616bd6c7340f1d8a5dc8c209376a76451f
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-io.git
> > --branch commons-io-2.12.0-RC1 commons-io-2.12.0-RC1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1633/commons-io/commons-io/2.12.0/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Fri Apr 28 17:58:50 EDT 2023
> >
> > commons-io-2.12.0-bin.tar.gz=f291190a52b594300ba5df32ae2698378b56f999c1d6bd5391f277ff5e8c4f2deaf153e753e7377614949c9b69551b8897b0a6bad9f0a34f0c52d7a2c0b02344
> >
> > commons-io-2.12.0-bin.zip=82f4cc82aa4e2b099afd552b7df21d7d882c7fa1ce7d1abef5023d361a1861ca62a50098caae7c905d7a077283ec618b2b81f2c446f66fd6c2bdd0df38d02700
> >
> > commons-io-2.12.0-bom.json=44d65999a06397b2c22499d6488315f9dc40a7065547b922ca4d16ddc64d1679905a080cbd63151a7e7a0a68204b11313778cc2cc980959cd2273d322a08
> >
> > commons-io-2.12.0-bom.xml=2dec492e9758870eb6802c905bf7ce41a17b64d69722d1e1476600682d3859b1465cbcc9f6015702f7c9bfb3e581b122d11dad7054923b332d0ec4044c9612d4
> >
> > commons-io-2.12.0-javadoc.jar=6ce2924eeca7fdaf3caceb0cd75df7ee584d3232c7b975a9b74442464bbd6da0dfb77132aabfdece2fa6e29a852255862f9a2add38b1c5969733667e248a509a
> >
> > commons-io-2.12.0-sources.jar=e31349d8480d6c8f3e91abc743076f683d6dabf1bebf594118bb15269680b92d98260264105d5ebe5d1e42bdb3efbe96426c575d70e0dd7731184e7e94b74d39
> >
> > commons-io-2.12.0-src.tar.gz=f62d52cda73a42e1c63f339aa90d363ef4a37f378b49276b11ff7dcb5aae1a15aa8d4104daa97dd40d094d64b053566987495eb888162d166af7f61fe9a403b0
> >
> > commons-io-2.12.0-src.zip=85538dbf9d57e381bd8a62e46caf0e5d97e18b4b960b3cdc5bb54d45dc420ad98ae9bae8d243f70bd609ea99d4e07e6188fac7ca4cb80a011f1331e46d03a6ce
> >
> > commons-io-2.12.0-test-sources.jar=31e7aa90d6f062a8f3fd9de5189f24878b080ea172d9286eb41e8c552b87bff4fc8202dd25e431ea5eb9ad7db9a8bb51471d680cb61003565426b506292277ff
> >
> > commons-io-2.12.0-tests.jar=054f2dac25b2afa352ce8f80a024d13cc49ab9a8bf3dff426698ba2b3b95c5d0092b906de8bc707a120f298069ed8f4b2154342a53d25038dcdfc3e2a3a1cc93
> >
> > commons-io_commons-io-2.12.0.spdx.json=1375bad0d00979da1b86b304ca39ff52e1a693ed2a85ce7f29ba26734f5a71a837ebb57278727357f7450ede1ad3c671713dc708fbffdf19af381840cf1dafc3
> >
> > I have tested this with 'mvn' (the default Maven goal) using:
> >
> > Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> > Maven home: /usr/local/Cellar/maven/3.9.1/libexec
> > Java version: 1.8.0_372, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@8
> > /1.8.0+372/libexec/openjdk.jdk/Contents/Home/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "13.3.1", arch: "x86_64", family: "mac"
> > Darwin  22.4.0 Darwin Kernel Version 22.4.0: Mon Mar  6 21:00:17
> > PST 2023; root:xnu-8796.101.5~3/RELEASE_X86_64 x86_64
> >
> > Details of changes since 2.11.0 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/io/2.12.0-RC1/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/io/2.12.0-RC1/site/changes-report.html
> >
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/io/2.12.0-RC1/site/index.html
> > (note some *relative* links are broken and the 2.12.0 directories
> > are not yet created - these will be OK once the site is deployed.)
> >
> > JApiCmp Report (compared to 2.11.0):
> >
> > https://dist.apache.org/repos/dist/dev/commons/io/2.12.0-RC1/site/japicmp.html
> >
> > RAT Report:
> >
> > https://dist.apache.org/repos/dist/dev/commons/io/2.12.0-RC1/site/rat-report.html
> >
> > KEYS:
> >   https://www.apache.org/dist/commons/KEYS
> >
> > Please review the release 

Re: [IO] IO-769: FileUtils copyDirectory() should not use COPY_ATTRIBUTES #377

2023-04-18 Thread Gary D. Gregory
Merged https://github.com/apache/commons-io/pull/377, see the PR for behavior.

For the upcoming 2.12.0, COPY_ATTRIBUTES is no longer used by default.

Gary

On 2023/04/17 12:27:09 Gary Gregory wrote:
> Hi All,
> 
> I would like to get some ideas and consensus on how to proceed with
> https://github.com/apache/commons-io/pull/377
> 
> Thank you,
> Gary
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



[BCEL] https://github.com/apache/commons-bcel/pull/177

2023-04-10 Thread Gary D. Gregory
Mark and all,

Any thoughts on https://github.com/apache/commons-bcel/pull/177 ?

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



[JEXL] Compatibility bug?

2023-04-07 Thread Gary D. Gregory
Hi All

Did we create a bug in the recently released 3.3 which surfaces as 
https://github.com/apache/commons-scxml/pull/121 ?

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



[math] The build is broken

2023-03-04 Thread Gary D. Gregory
Hi Math,

The build is broken locally for me, and as exemplified on GHA [1]: 
https://github.com/apache/commons-math/actions/runs/4086106809/jobs/7044975362

Please fix.

Gary
[1] https://github.com/apache/commons-math/actions

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



[POOL] GenericKeyedObjectPool.clear(K) vs clear()

2023-03-01 Thread Gary D. Gregory
Hi All,

Looking at org.apache.commons.pool2.impl.GenericKeyedObjectPool.clear(K) and 
clear(), I am wondering why the former calls clear(K, boolean) with true while 
the latter calls it with false.

Surely both should call clear(K, boolean) with the same value.

Any ideas?

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



[lang] excluding fields in ReflectionDiffBuilder

2023-02-11 Thread Gary D. Gregory
Hi All:

I'd like another set of eyes on https://github.com/apache/commons-lang/pull/838

Is this one OK merge?

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [VOTE] Release Apache Commons Parent 56 based on RC1

2022-12-30 Thread Gary D. Gregory
I forgot to say this is a LAZY VOTE.

Gary

On 2022/12/30 16:27:22 Gary Gregory wrote:
> We have added some enhancements since Apache Commons Parent 55 was
> released, so I would like to release Apache Commons Parent 56.
> 
> Apache Commons Parent 56 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/56-RC1
> (svn revision 59034)
> 
> The Git tag commons-parent-56-RC1 commit for this RC is
> 5b9c51eb767743b4e8c6405813b7082926659b98 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=5b9c51eb767743b4e8c6405813b7082926659b98
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-56-RC1 commons-parent-56-RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1614/org/apache/commons/commons-parent/56/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Fri Dec 30 11:18:57 EST 2022
> commons-parent-56-bom.json=fb85672b30edcc1dfba3ff5b45d2ab8d98616e428733d30494eb15870b61166ab9915b2fe5c26f0093699e78389ca6808f8a47fb89b8059c9725b131a5b6c2fa
> commons-parent-56-bom.xml=5ffe9849ba1b038bee2cdd0c440eb8872d2c1f7ca0f4262363544f61e57675f1e209c2f5eec06dc978e20b57853faaddaae16e58dbb9b111e3d78ac3c05d6770
> commons-parent-56-site.xml=c6aea4f2c03920366bee23b08b046dacc09710e92c78ccd83f47cd92f89bc53abc3b8bbc7f44017ee94a2cb022ce763fe3f7d8c9aa42d571350269ba6568ca07
> commons-parent-56-src.tar.gz=6c3831c0ca6cf22b610b0362093c4b1467571e2c1fc3c4398b7cdaa636375f289d4b52d62a2ef1a42e485b5241316b7599066c25464ac148db49c7a3339c6692
> commons-parent-56-src.zip=a6af3b55474c568a3b48fb7e75adfa11b105b2e23c8a5f522d717a6434403cb3981c9b5867ae06177c4e15fa9b82a3de5295b5f4e7faa66c90ea1a23056e7896
> org.apache.commons_commons-parent-56.spdx.json=032a54626a692686b574708ef33ac5c9f93a48e0a567abafcf73281142354acc7c129e03d10de2145288d84b6aa329896e1fcaa3ee34ac85d8c4e648d8ef09a1
> 
> I have tested this with 'mvn -V -Duser.name=$my_apache_id
> -Ddoclint=none -Prelease -Ptest-deploy clean package site deploy'
> using:
> 
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> Java version: 1.8.0_352, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8/1.8.0+352/libexec/openjdk.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "13.1", arch: "x86_64", family: "mac"
> 
> Darwin  22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:08:47
> PST 2022; root:xnu-8792.61.2~4/RELEASE_X86_64 x86_64
> 
> Details of changes since 55 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/56-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/56-RC1/site/changes-report.html
> 
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/56-RC1/site/index.html
> (note some *relative* links are broken and the 56 directories are
> not yet created - these will be OK once the site is deployed.)
> 
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/56-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,
> 
> garydgregory,
> Release Manager (using key DEADBEEF)
> 
> 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-parent.git
> --branch commons-parent-56-RC1 commons-parent-56-RC1
> cd commons-parent-56-RC1
> 
> 1b) Download and unpack the source archive from:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/56-RC1/source
> 
> 2) Check Apache licenses
> 
> This step is not required if the site includes a RAT report page which
> you then must check.
> 
> mvn apache-rat:check
> 
> 3) Check binary compatibility
> 
> Older components still use Apache Clirr:
> 
> This step is not required if the site includes a Clirr report page
> which you then must check.
> 
> mvn clirr:check
> 
> Newer components use JApiCmp with the japicmp Maven Profile:
> 
> This step is not required if the site includes a JApiCmp report page
> which you then must check.
> 
> mvn install -DskipTests -P japicmp japicmp:cmp
> 
> 4) Build the package
> 
> mvn -V clean package
> 
> You can record the Maven and Java version produced by -V in your VOTE reply.
> To 

[REPORT] Board report for this quarter

2022-12-15 Thread Gary D. Gregory
This is what I submitted for our board report for this quarter:

## Description:
The mission of Apache Commons is the creation and maintenance of Java focused 
reusable libraries and components

## Issues:
There are no issues requiring board attention.

## Membership Data:
Apache Commons was founded 2007-06-19 (15 years ago)
There are currently 149 committers and 42 PMC members in this project.
The Committer-to-PMC ratio is roughly 5:2.

Community changes, past quarter:
- No new PMC members. Last addition was Matt Juntunen on 2021-06-25.
- No new committers. Last addition was Claude Warren on 2022-02-01.

## Project Activity:
The Apache Commons teams has been following up of security reports, bug fixes,
adding features, and have released many components:

- PARENT-55 was released on 2022-12-11.
- BCEL-6.7.0 was released on 2022-12-06.
- STATISTICS-1.0 was released on 2022-12-06.
- NET-3.9.0 was released on 2022-12-01.
- DAEMON-1.3.3 was released on 2022-11-29.
- BCEL-6.6.1 was released on 2022-11-03.
- NUMBERS-1.1 was released on 2022-11-01.
- COMPRESS-1.22 was released on 2022-10-31.
- BCEL-6.6.0 was released on 2022-10-12.
- DAEMON-1.3.2 was released on 2022-10-10.
- RNG-1.5 was released on 2022-10-10.
- TEXT-1.10.0 was released on 2022-09-29.

The latest release of Apache Commons BCEL will allow Apache Xalan to continue 
its release process.

## Community Health:
The community is active in many components with commit activity much higher
this quarter with a 40% increase, all the while mailing list activity is down.
We are seeing a lot of input from GitHub PRs.

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [VOTE][LAZY] Release Apache Commons Parent 55 based on RC1

2022-12-08 Thread Gary D. Gregory
Hi Alex,

Thank you for your review. I cannot reproduce your error. I tested locally now 
with commons-parent git master 55-SNAPSHOT with commons-text (the component I 
tested for the RC), commons-lang, and commons-rng.

For 'mvn install -DskipTests', I see output like:

...
[INFO] <<< spdx-maven-plugin:0.6.3:createSPDX (build-spdx) < verify @ 
commons-lang3 <<<
[INFO]
[INFO]
[INFO] --- spdx-maven-plugin:0.6.3:createSPDX (build-spdx) @ commons-lang3 ---
[INFO] Creating SPDX File 
C:\Users\ggregory\git\a\commons-lang\target\site\org.apache.commons_commons-lang3-3.13.0-SNAPSHOT.spdx.json
[WARNING] Unable to map maven licenses to a declared license.  Using NOASSERTION
[WARNING] Could not determine the SPDX relationship type for dependency 
artifact ID commons-text scope provided
[WARNING] Could not determine the SPDX relationship type for dependency 
artifact ID commons-lang3 scope provided
[INFO]
...

My output for commons-rng is here: https://paste.apache.org/sml51

All I did is edit the parent POM version in the root pom.xml

I am running with:

Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: C:\java\apache-maven-3.8.6
Java version: 1.8.0_352, vendor: Temurin, runtime: C:\Program Files\Eclipse 
Adoptium\jdk-8.0.352.8-hotspot\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Microsoft Windows [Version 10.0.19044.2251]

Gary

On 2022/12/08 13:18:46 Alex Herbert wrote:
> Hi Gary,
> 
> I tried with the latest git master for numbers, rng and lang. The
> updated spdx-maven-plugin is not compatible with java 8. I get the
> following error:
> 
> [ERROR] Failed to execute goal
> org.spdx:spdx-maven-plugin:0.6.3:createSPDX (build-spdx) on project
> commons-lang3: Execution build-spd
> x of goal org.spdx:spdx-maven-plugin:0.6.3:createSPDX failed: An API
> incompatibility was encountered while executing org.spdx:spdx-ma
> ven-plugin:0.6.3:createSPDX: java.lang.UnsupportedClassVersionError:
> org/spdx/spdxRdfStore/RdfStore has been compiled by a more recen
> t version of the Java Runtime (class file version 55.0), this version
> of the Java Runtime only recognizes class file versions up to 5
> 2.0
> 
> mvn -v
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/apache-maven-3
> Java version: 1.8.0_352, vendor: Private Build, runtime:
> /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-200-generic", arch: "amd64", family: "unix"
> 
> Note: I am not clear exactly what the issue is as it does not happen
> in the first jar module of the rng project reactor. The first module
> commons-rng-client-api has no dependencies and this builds ok. The
> next module commons-rng-core only depends on the client-api. This also
> builds. The reactor breaks on the simple module which depends on core
> and the client-api. However in numbers the reactor breaks on the first
> module commons-numbers-core. This has no runtime dependencies. So some
> part of the spdx plugin is being invoked only in some modules that has
> a class compiled for Java 11.
> 
> Building under JDK 11 was fine for all 3 named projects.
> 
> Note that numbers and rng previously had  set to true
> as the configuration in CP 54 broke the build. I changed to false and
> the multi-module build was fine.
> 
> mvn -v
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/apache-maven-3
> Java version: 11.0.17, vendor: Ubuntu, runtime:
> /usr/lib/jvm/java-11-openjdk-amd64
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-200-generic", arch: "amd64", family: "unix"
> 
> So cyclonedx is fixed, but spdx is now not Java 8 compatible.
> 
> Alex
> 
> On Wed, 7 Dec 2022 at 19:50, Gary Gregory  wrote:
> >
> > We made some enhancements since Apache Commons Parent 54 was released,
> > so I would like to release Apache Commons Parent 55.
> >
> > This is the parent POM for Apache Commons, it doesn't contain Java
> > code, and therefore no JApiCmp API compatibility check or report on
> > the site.
> >
> > Apache Commons Parent 55 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/commons-parent/55-RC1
> > (svn revision 58537)
> >
> > The Git tag commons-parent-55-RC1 commit for this RC is
> > 1a8382d227787216d76c1fea62b641158d0a265e which you can browse here:
> > 
> > https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=1a8382d227787216d76c1fea62b641158d0a265e
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> > --branch commons-parent-55-RC1 commons-parent-55-RC1
> >
> > Maven artifacts are here:
> > 
> > https://repository.apache.org/content/repositories/orgapachecommons-1611/org/apache/commons/commons-parent/55/
> >
> > These are the artifacts and their hashes:
> >
> > #Release 

CVE-2021-37533: Apache Commons Net's FTP client trusts the host from PASV response by default

2022-12-03 Thread Gary D. Gregory
Severity: low

Description:

Prior to Apache Commons Net 3.9.0, Net's FTP client trusts the host from PASV 
response by default. A malicious server can redirect the Commons Net code to 
use a different host, but the user has to connect to the malicious server in 
the first place. This may lead to leakage of information about services running 
on the private network of the client.
The default in version 3.9.0 is now false to ignore such hosts, as cURL does. 
See https://issues.apache.org/jira/browse/NET-711.


This issue is being tracked as NET-711

Credit:

Apache Commons would like to thank ZeddYu Lu for reporting this issue.


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [VOTE] Release Apache Commons Net 3.9.0 based on RC1

2022-12-01 Thread Gary D. Gregory
We need more reviews please.

Gary

On 2022/11/29 21:32:31 Gary Gregory wrote:
> Ping ;-)
> 
> Gary
> 
> On Sat, Nov 26, 2022, 22:02 Gary Gregory  wrote:
> 
> > We have fixed quite a few bugs and added some enhancements since Apache
> > Commons Net 3.8.0 was released, so I would like to release Apache Commons
> > Net 3.9.0.
> >
> > Apache Commons Net 3.9.0 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/net/3.9.0-RC1 (svn
> > revision 58255)
> >
> > The Git tag commons-net-3.9.0-RC1 commit for this RC is
> > 1595ad2cbb5b7d7e055613c1a76a3a4c82318aee which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-net.git;a=commit;h=1595ad2cbb5b7d7e055613c1a76a3a4c82318aee
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-net.git
> > --branch commons-net-3.9.0-RC1 commons-net-3.9.0-RC1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1607/commons-net/commons-net/3.9.0/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Sat Nov 26 16:08:42 EST 2022
> > Apache\ Commons\
> > Net-3.9.0.spdx.rdf.xml=86bd182d31b6cfbfbb9402a77bc17f1bcfc7e9a4de0ce3c42f651cf9db6705360f9cc0973b2720a5df5a9c2d142c947ffd196edec7c54d46328a83a8e1218304
> >
> > commons-net-3.9.0-bin.tar.gz=98b5ed975d07a825577e240ab463c58b32874e30225755051f5f66ba008ad6c21cbebb50ca15665835c7189bf222baea16e94bc4ddf7c301da2742f16071718a
> >
> > commons-net-3.9.0-bin.zip=129a1382e33f5b9aad9001a98c7fd17d1033eff97f2f1cf805d3190ece2aa7860f425000e4f3d79171144fe8d591f36d35210da323ecb124ab7d01023d981341
> >
> > commons-net-3.9.0-bom.json=19ab24fab9f3dcee2d430bf43a89725ab3477056e2a11f6a19f5e134e6a39d9f9613c1314924889af1d09bddef2014fe328c74036a6d665474b33c11c3e92003
> >
> > commons-net-3.9.0-bom.xml=5992a52897a6db29e84ef9cd25dc2eb67b4f1f48937e001215903a4788fef455355b7fef6d556bba46a89a7286c402b281e58dd1078dd0fe52738ec2bf08c798
> >
> > commons-net-3.9.0-javadoc.jar=607a103b623d24872654f864eb5d803c5fd2bb177b229c6c1f791ff040fb6c1ca8d141fac0362f1f5716e7784db38de078ecd530d3dfbb94c472b06f749547a9
> >
> > commons-net-3.9.0-sources.jar=2fa5e645b5913394ab240443d73957c18173272c2004355bdcd0936ef40be73d7577e6c3167c49b5649f0899465c9c17de12dfba1e3dd179c7924f10f96ceac0
> >
> > commons-net-3.9.0-src.tar.gz=a2d4ef4937701f28304fdb9a39a0d4a8fdd5fd7ae84c6d647a6b9e05eee68cb4fde8ae9eedd94f45fdc0194d160dd9f64b3c1cfbdd8bcea2214e9826ace32877
> >
> > commons-net-3.9.0-src.zip=553a105ca2b624e13f9e7713084680477af87cb2d6d365f1075f6daa06ee1cda17f945ebf7983e3fd3ee04ed5ab9524365ed115f54cfeb730661cd9ec9832a9b
> >
> > commons-net-3.9.0-test-sources.jar=689220026210f434ef9bc53647a0567ba55e15cd9583229fc4187f8252c3766a3c943fe3f20c438bb8e1e06182d509c90c01013de4cebaa767f59b733475fd7a
> >
> > commons-net-3.9.0-tests.jar=5fea125ba37a40f7da1a0ad27191cad36e3892bf8c7820b998cf8780ef63e09ac75bb5a3fc3a177e4ac4467cd69c1e862572dbcf7778b4f930bf8df91c96f684
> >
> > commons-net-examples-3.9.0.jar=4620fed9f7296f2e840edaa79fcf773a401f0153935ff30bb591f6acc8ee3f6765dca9ba697b07b395ede07039f237ebfeda532f558620ecb4323b223f26ffd4
> >
> > commons-net-ftp-3.9.0.jar=1e477c00ac5f404f701cbd2b6cb4bf6971283621dd0561aa21232c3f8bcd3195a6a5d99723a73db0bec0d66fa2e79361bc5330540ddce8c1d45bc887c8c05962
> >
> > I have tested this with 'mvn -V -Duser.name=$my_apache_id -Prelease
> > -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
> >
> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> > Java version: 1.8.0_352, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@8
> > /1.8.0+352/libexec/openjdk.jdk/Contents/Home/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "13.0.1", arch: "x86_64", family: "mac"
> > Darwin .local 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct  9 20:14:54
> > PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64 x86_64
> >
> > Details of changes since 3.8.0 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/net/3.9.0-RC1/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/net/3.9.0-RC1/site/changes-report.html
> >
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/net/3.9.0-RC1/site/index.html
> > (note some *relative* links are broken and the 3.9.0 directories are
> > not yet created - these will be OK once the site is deployed.)
> >
> > JApiCmp Report (compared to 3.8.0):
> > Binary compatibility can be confirmed by running 'mvn' or 'mvn
> > japicmp:cmp'
> >
> > RAT Report:
> >
> > https://dist.apache.org/repos/dist/dev/commons/net/3.9.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 

Re: [VOTE] Release Apache Commons Net 3.9.0 based on RC1

2022-12-01 Thread Gary D. Gregory
We need more reviews please.

Gary

On 2022/11/29 21:32:31 Gary Gregory wrote:
> Ping ;-)
> 
> Gary
> 
> On Sat, Nov 26, 2022, 22:02 Gary Gregory  wrote:
> 
> > We have fixed quite a few bugs and added some enhancements since Apache
> > Commons Net 3.8.0 was released, so I would like to release Apache Commons
> > Net 3.9.0.
> >
> > Apache Commons Net 3.9.0 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/net/3.9.0-RC1 (svn
> > revision 58255)
> >
> > The Git tag commons-net-3.9.0-RC1 commit for this RC is
> > 1595ad2cbb5b7d7e055613c1a76a3a4c82318aee which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-net.git;a=commit;h=1595ad2cbb5b7d7e055613c1a76a3a4c82318aee
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-net.git
> > --branch commons-net-3.9.0-RC1 commons-net-3.9.0-RC1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1607/commons-net/commons-net/3.9.0/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Sat Nov 26 16:08:42 EST 2022
> > Apache\ Commons\
> > Net-3.9.0.spdx.rdf.xml=86bd182d31b6cfbfbb9402a77bc17f1bcfc7e9a4de0ce3c42f651cf9db6705360f9cc0973b2720a5df5a9c2d142c947ffd196edec7c54d46328a83a8e1218304
> >
> > commons-net-3.9.0-bin.tar.gz=98b5ed975d07a825577e240ab463c58b32874e30225755051f5f66ba008ad6c21cbebb50ca15665835c7189bf222baea16e94bc4ddf7c301da2742f16071718a
> >
> > commons-net-3.9.0-bin.zip=129a1382e33f5b9aad9001a98c7fd17d1033eff97f2f1cf805d3190ece2aa7860f425000e4f3d79171144fe8d591f36d35210da323ecb124ab7d01023d981341
> >
> > commons-net-3.9.0-bom.json=19ab24fab9f3dcee2d430bf43a89725ab3477056e2a11f6a19f5e134e6a39d9f9613c1314924889af1d09bddef2014fe328c74036a6d665474b33c11c3e92003
> >
> > commons-net-3.9.0-bom.xml=5992a52897a6db29e84ef9cd25dc2eb67b4f1f48937e001215903a4788fef455355b7fef6d556bba46a89a7286c402b281e58dd1078dd0fe52738ec2bf08c798
> >
> > commons-net-3.9.0-javadoc.jar=607a103b623d24872654f864eb5d803c5fd2bb177b229c6c1f791ff040fb6c1ca8d141fac0362f1f5716e7784db38de078ecd530d3dfbb94c472b06f749547a9
> >
> > commons-net-3.9.0-sources.jar=2fa5e645b5913394ab240443d73957c18173272c2004355bdcd0936ef40be73d7577e6c3167c49b5649f0899465c9c17de12dfba1e3dd179c7924f10f96ceac0
> >
> > commons-net-3.9.0-src.tar.gz=a2d4ef4937701f28304fdb9a39a0d4a8fdd5fd7ae84c6d647a6b9e05eee68cb4fde8ae9eedd94f45fdc0194d160dd9f64b3c1cfbdd8bcea2214e9826ace32877
> >
> > commons-net-3.9.0-src.zip=553a105ca2b624e13f9e7713084680477af87cb2d6d365f1075f6daa06ee1cda17f945ebf7983e3fd3ee04ed5ab9524365ed115f54cfeb730661cd9ec9832a9b
> >
> > commons-net-3.9.0-test-sources.jar=689220026210f434ef9bc53647a0567ba55e15cd9583229fc4187f8252c3766a3c943fe3f20c438bb8e1e06182d509c90c01013de4cebaa767f59b733475fd7a
> >
> > commons-net-3.9.0-tests.jar=5fea125ba37a40f7da1a0ad27191cad36e3892bf8c7820b998cf8780ef63e09ac75bb5a3fc3a177e4ac4467cd69c1e862572dbcf7778b4f930bf8df91c96f684
> >
> > commons-net-examples-3.9.0.jar=4620fed9f7296f2e840edaa79fcf773a401f0153935ff30bb591f6acc8ee3f6765dca9ba697b07b395ede07039f237ebfeda532f558620ecb4323b223f26ffd4
> >
> > commons-net-ftp-3.9.0.jar=1e477c00ac5f404f701cbd2b6cb4bf6971283621dd0561aa21232c3f8bcd3195a6a5d99723a73db0bec0d66fa2e79361bc5330540ddce8c1d45bc887c8c05962
> >
> > I have tested this with 'mvn -V -Duser.name=$my_apache_id -Prelease
> > -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
> >
> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> > Java version: 1.8.0_352, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@8
> > /1.8.0+352/libexec/openjdk.jdk/Contents/Home/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "13.0.1", arch: "x86_64", family: "mac"
> > Darwin .local 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct  9 20:14:54
> > PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64 x86_64
> >
> > Details of changes since 3.8.0 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/net/3.9.0-RC1/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/net/3.9.0-RC1/site/changes-report.html
> >
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/net/3.9.0-RC1/site/index.html
> > (note some *relative* links are broken and the 3.9.0 directories are
> > not yet created - these will be OK once the site is deployed.)
> >
> > JApiCmp Report (compared to 3.8.0):
> > Binary compatibility can be confirmed by running 'mvn' or 'mvn
> > japicmp:cmp'
> >
> > RAT Report:
> >
> > https://dist.apache.org/repos/dist/dev/commons/net/3.9.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 

Re: [VOTE] Release Apache Commons Daemon 1.3.3 based on RC1

2022-11-23 Thread Gary D. Gregory
Testing src zip: ASC, SHA, Apache RAT, Maven default goal, JApiCmp, all OK on:

Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: C:\java\apache-maven-3.8.6
Java version: 1.8.0_352, vendor: Temurin, runtime: C:\Program Files\Eclipse 
Adoptium\jdk-8.0.352.8-hotspot\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Microsoft Windows [Version 10.0.19044.2130]

Building Windows natives OK using 'nmake CPU=X64' with:

Microsoft (R) Program Maintenance Utility Version 14.33.31630.0
Microsoft (R) C/C++ Optimizing Compiler Version 19.33.31630 for x64
Microsoft (R) Incremental Linker Version 14.33.31630.0

Gary

On 2022/11/23 20:45:07 Mark Thomas wrote:
> We have fixed a few bugssince Apache Commons Daemon 1.3.2 was released, 
> so I would like to release Apache Commons Daemon 1.3.3.
> 
> Apache Commons Daemon 1.3.3 RC1 is available for review here:
>  https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.3-RC1 
> (svn revision svn: 58217
> 
> The Git tag commons-daemon-1.3.3-RC1 commit for this RC is 
> 5ead75b56ce0e171931de808bf0529666c1c4cbb which you can browse here:
>  
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=5ead75b56ce0e171931de808bf0529666c1c4cbb
> You may checkout this tag using:
>  git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
> --branch commons-daemon-1.3.3-RC1 commons-daemon-1.3.3-RC1
> 
> Maven artifacts are here:
>  
> https://repository.apache.org/content/repositories/orgapachecommons-1606/commons-daemon/commons-daemon/1.3.3/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> commons-daemon-1.3.3.jar=ee877434645400193ef5578f52e1314e90604c28224a77d03176c1370e7bcdae393d62238bce371b4cbb1495b867c06d2bf6a33ea1ab3aea56c2b872ea2b0b6c
> Apache Commons 
> Daemon-1.3.3.spdx.rdf.xml=c7c4416afbe3b14d62c94d5b1da413794ac0db8732c51453a1bb39677a0e564af245a6ab8bc4f2d66ac95b6b594faa208ec2da12ac66241c47db6e853d141a5f
> commons-daemon-1.3.3-bin-windows.zip=f291b142dadb179fee6845b4d26a52e7961bd39e57680ce2398505efe8c04de00271ed35bc39392c82d1e2d0f60b868cc5a1e80a7b8af8de923554877e0003ba
> commons-daemon-1.3.3-bin.tar.gz=6600f3c182a46005928a77ade2a7f7e32ba29ebdfdc2255275cbd07445c4d278a96de4d8555031fa90eef29c4f50325b3b79eec0e4e09308d152583807189578
> commons-daemon-1.3.3-bin.zip=ef89d6cac12b7f90575ccfeca0d58ed96f8d2dca702946882d54fa10df5f770ba9c08097951589f8704419a8e14b205cd95135c5bc12a59107ef5ee84db17fa9
> commons-daemon-1.3.3-bom.json=d199cc4ac629f0b7cde86ab4084251dbb57b20a8d94d3086d5d6e0533e77a0f07d01b4326059e645d4eec2f460f144b79376cae95e1ba619fc96a4caaa0465e3
> commons-daemon-1.3.3-bom.xml=e299fd88c34c9eb4ecd431f83f43a4aa978d6d123ffc5d14ffc718826832ff1972dc3b3fb944ceca4c608185d2edcb32e91ea3d2aab10e2a4e3812a4ba872887
> commons-daemon-1.3.3-javadoc.jar=64423f84f26633748c61d7c2e34c6e6283d35ec95ccc162c5dcdd28bc5fa73222181fe429304a93b1de32b63385f14301f52fa44c02f710cc6a9a62b6fef6730
> commons-daemon-1.3.3-native-src.tar.gz=a3d200e5c35c4f2d397164fbaee52f235d954ba8fe342bf136fb2a7da3ca2df472af31c7f68d71b114ab3632ac712f6c7b7a3d3043f8e754c58c402658e1
> commons-daemon-1.3.3-native-src.zip=bbd9ea0b6b8438c305a537dd30d3754fe8cda33af7cd416b039548f4a33a1afbde295590e98801f75ad73a0aefb512aa91f8c0b1dd716c332facd6ace0cce646
> commons-daemon-1.3.3-sources.jar=a7179691a4c7fabdd379d8b6ca9b221bd792382439ebff7dc618d1c6f287a77defe2e5a85d594da618ecb14c8b5062560c9e09c9ccebab0d0527cda42d618159
> commons-daemon-1.3.3-src.tar.gz=ec246e2c05d66408374ba56b3715b13f8f24f89af11fa00c2381dc19c188f1b6228f19351c97d5774808a804b83fdbdfb8f537d099db062c39ffd281c142ee77
> commons-daemon-1.3.3-src.zip=d622db66ea21ac6c1b096506173d1e66c7c2e5db49cefaeac818fe6f106c32c2daef946a9c6faf8c664716fc8acb7501d5e5e0c6faf66ab02d7c94849b21df19
> 
> 
> 
> 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,
> 
> Mark Thomas,
> Release Manager (using key 10C01C5A2F6059E7)
> 
> 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.
> 
> 1) Clone and checkout the RC tag
> 
> git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
> --branch commons-daemon-1.3.3-RC1 commons-daemon-1.3.3-RC1
> cd commons-daemon-1.3.3-RC1
> 
> 2) Check Apache licenses
> 
> This step is not required if the site includes a RAT report page which 
> you then must check.
> 
> mvn apache-rat:check
> 
> 3) Check binary compatibility
> 
> Older components still use Apache Clirr:
> 
> This step is not required if the site 

Re: [commons-bcel] branch master updated: Validate the u4 length of all attributes

2022-11-22 Thread Gary D. Gregory
I am concerned that the recent fixes we've made through OSS fuzz and code 
inspection to validate input are semantically incorrect: The verifier should 
catch these errors, not the construction of Java objects. This could be a case 
where fuzzing and low-level code inspections only appear to find issues but are 
ignorant of the usage context.

Thoughts?

Gary

On 2022/11/21 14:04:38 Gary Gregory wrote:
> Gotcha, will fix.
> 
> Gary
> 
> On Mon, Nov 21, 2022, 08:23 Mark Thomas  wrote:
> 
> > On 21/11/2022 13:03, ggreg...@apache.org wrote:
> > > 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-bcel.git
> > >
> > >
> > > The following commit(s) were added to refs/heads/master by this push:
> > >   new 428b65e0 Validate the u4 length of all attributes
> > > 428b65e0 is described below
> > >
> > > commit 428b65e0d6cc0f094b428f8ab92810ad7221afe1
> > > Author: Gary David Gregory (Code signing key) 
> > > AuthorDate: Mon Nov 21 08:03:04 2022 -0500
> > >
> > >  Validate the u4 length of all attributes
> >
> > This breaks the format of the error message for four byte unsigned int
> > values bigger than Integer.MAX_VALUE
> >
> > The "length & 0xL" snippet was there to ensure that these were
> > correctly displayed as a positive (long) integer.
> >
> > Mark
> >
> >
> > > ---
> > >   src/changes/changes.xml|  2 +-
> > >   .../java/org/apache/bcel/classfile/Attribute.java  | 37
> > ++
> > >   .../java/org/apache/bcel/classfile/Unknown.java| 10 +-
> > >   src/main/java/org/apache/bcel/util/Args.java   | 28
> > 
> > >   4 files changed, 61 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > > index 502b818f..30a26c71 100644
> > > --- a/src/changes/changes.xml
> > > +++ b/src/changes/changes.xml
> > > @@ -98,7 +98,7 @@ The  type attribute can be
> > add,update,fix,remove.
> > > org.apache.bcel.util.ClassPath hashCode() and equals() don't
> > match.
> > >  > due-to="OSS-Fuzz">org.apache.bcel.classfile.StackMapType constructors now
> > throw ClassFormatException on invalid input.
> > >  > due-to="nbauma109, Gary Gregory">Code coverage and bug fixes for bcelifier
> > #171.
> > > -  org.apache.bcel.classfile.Unknown constructors now throw
> > ClassFormatException on invalid length input.
> > > +  org.apache.bcel.classfile.Attribute constructors now
> > throw ClassFormatException on invalid length input.
> > > 
> > >  > due-to="Gary Gregory">Bump spotbugs-maven-plugin from 4.7.2.2 to 4.7.3.0
> > #167.
> > >  > due-to="Dependabot">Bump jmh.version from 1.35 to 1.36 #170.
> > > diff --git a/src/main/java/org/apache/bcel/classfile/Attribute.java
> > b/src/main/java/org/apache/bcel/classfile/Attribute.java
> > > index d1d38f40..14a76cc2 100644
> > > --- a/src/main/java/org/apache/bcel/classfile/Attribute.java
> > > +++ b/src/main/java/org/apache/bcel/classfile/Attribute.java
> > > @@ -27,9 +27,17 @@ import org.apache.bcel.Const;
> > >   import org.apache.bcel.util.Args;
> > >
> > >   /**
> > > - * Abstract super class for Attribute objects. Currently the
> > ConstantValue, SourceFile,
> > > - * Code, Exceptiontable, LineNumberTable,
> > LocalVariableTable, InnerClasses
> > > - * and Synthetic attributes are supported. The
> > Unknown attribute stands for non-standard-attributes.
> > > + * Abstract super class for Attribute objects. Currently the
> > ConstantValue, SourceFile, Code,
> > Exceptiontable,
> > > + * LineNumberTable, LocalVariableTable,
> > InnerClasses and Synthetic attributes are supported. The
> > Unknown attribute
> > > + * stands for non-standard-attributes.
> > > + *
> > > + * 
> > > + * attribute_info {
> > > + *   u2 attribute_name_index;
> > > + *   u4 attribute_length;
> > > + *   u1 info[attribute_length];
> > > + * }
> > > + * 
> > >*
> > >* @see ConstantValue
> > >* @see SourceFile
> > > @@ -238,10 +246,26 @@ public abstract class Attribute implements
> > Cloneable, Node {
> > >   @java.lang.Deprecated
> > >   protected ConstantPool constant_pool; // TODO make private (has
> > getter & setter)
> > >
> > > +/**
> > > + * Constructs an instance.
> > > + *
> > > + * 
> > > + * attribute_info {
> > > + *   u2 attribute_name_index;
> > > + *   u4 attribute_length;
> > > + *   u1 info[attribute_length];
> > > + * }
> > > + * 
> > > + *
> > > + * @param tag tag.
> > > + * @param nameIndex u2 name index.
> > > + * @param length u4 length.
> > > + * @param constantPool constant pool.
> > > + */
> > >   protected Attribute(final byte tag, final int nameIndex, final int
> > length, final ConstantPool constantPool) {
> > >   this.tag = tag;
> > >   this.name_index = 

Re: [commons-bcel] branch master updated: Unknown attributes with invalid length now trigger ClassFormatException

2022-11-21 Thread Gary D. Gregory
Hm, after reading 
https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7 I will 
pull up the validation.

TY for the commit :-)

Gary

On 2022/11/21 12:00:20 Gary Gregory wrote:
> Hi Mark,
> 
> Any reason not to do this check in the Attribute superclass?
> 
> Gaty
> 
> On Mon, Nov 21, 2022, 05:50  wrote:
> 
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > markt pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-bcel.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >  new 89015357 Unknown attributes with invalid length now trigger
> > ClassFormatException
> > 89015357 is described below
> >
> > commit 89015357e5559d0ae3e73b25801db08d7812
> > Author: Mark Thomas 
> > AuthorDate: Mon Nov 21 10:50:23 2022 +
> >
> > Unknown attributes with invalid length now trigger ClassFormatException
> > ---
> >  src/changes/changes.xml  |   1 +
> >  src/main/java/org/apache/bcel/classfile/Unknown.java |   8 
> >  src/test/java/org/apache/bcel/OssFuzzTestCase.java   |   9 +
> >  src/test/resources/ossfuzz/issue53544a/Test.class| Bin 0 -> 49 bytes
> >  4 files changed, 18 insertions(+)
> >
> > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > index ab28355f..502b818f 100644
> > --- a/src/changes/changes.xml
> > +++ b/src/changes/changes.xml
> > @@ -98,6 +98,7 @@ The  type attribute can be add,update,fix,remove.
> >org.apache.bcel.util.ClassPath hashCode() and equals() don't
> > match.
> > > due-to="OSS-Fuzz">org.apache.bcel.classfile.StackMapType constructors now
> > throw ClassFormatException on invalid input.
> > > due-to="nbauma109, Gary Gregory">Code coverage and bug fixes for bcelifier
> > #171.
> > +  org.apache.bcel.classfile.Unknown constructors now throw
> > ClassFormatException on invalid length input.
> >
> >Bump spotbugs-maven-plugin from 4.7.2.2 to 4.7.3.0 #167.
> > > due-to="Dependabot">Bump jmh.version from 1.35 to 1.36 #170.
> > diff --git a/src/main/java/org/apache/bcel/classfile/Unknown.java
> > b/src/main/java/org/apache/bcel/classfile/Unknown.java
> > index 23cd38eb..df088430 100644
> > --- a/src/main/java/org/apache/bcel/classfile/Unknown.java
> > +++ b/src/main/java/org/apache/bcel/classfile/Unknown.java
> > @@ -66,6 +66,14 @@ public final class Unknown extends Attribute {
> >  if (length > 0) {
> >  bytes = new byte[length];
> >  input.readFully(bytes);
> > +} else if (length < 0) {
> > +// Length is defined in the JVM specification as an unsigned
> > 4 byte
> > +// integer but is read as a signed integer. This is not an
> > issue as
> > +// the JRE API consistently uses byte[] or ByteBuffer for
> > classes.
> > +// Therefore treat any negative number here as a format error.
> > +throw new ClassFormatException(String.format(
> > +"Invalid length %,d for Unknown attribute. Must be
> > greater than or equal to zero and less than %,d",
> > +length & 0xL, Integer.MAX_VALUE));
> >  }
> >  }
> >
> > diff --git a/src/test/java/org/apache/bcel/OssFuzzTestCase.java
> > b/src/test/java/org/apache/bcel/OssFuzzTestCase.java
> > index 9f4e63bb..8944ca4b 100644
> > --- a/src/test/java/org/apache/bcel/OssFuzzTestCase.java
> > +++ b/src/test/java/org/apache/bcel/OssFuzzTestCase.java
> > @@ -47,6 +47,15 @@ public class OssFuzzTestCase {
> >  testOssFuzzReproducer("53543");
> >  }
> >
> > +/*
> > + * The original issue 53544 was a false positive but reviewing that
> > issue
> > + * did find a valid issue nearby.
> > + */
> > +@Test
> > +public void testIssue53544a() throws Exception {
> > +testOssFuzzReproducer("53544a");
> > +}
> > +
> >  private void testOssFuzzReproducer(final String issue) throws
> > Exception {
> >  final File reproducerFile = new
> > File("target/test-classes/ossfuzz/issue" + issue + "/Test.class");
> >  try (final FileInputStream reproducerInputStream = new
> > FileInputStream(reproducerFile)) {
> > diff --git a/src/test/resources/ossfuzz/issue53544a/Test.class
> > b/src/test/resources/ossfuzz/issue53544a/Test.class
> > new file mode 100644
> > index ..5fbdd67f
> > Binary files /dev/null and
> > b/src/test/resources/ossfuzz/issue53544a/Test.class differ
> >
> >
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [BCEL] Invalid test or bug?

2022-11-19 Thread Gary D. Gregory
Mark,

What I had in mind (compared to your diff) file, is something like this:

https://paste.apache.org/oxn8x

Note that this fixed throwing the exception but there are still many JRE 
classes that fail to verify.

Gary

On 2022/11/19 15:32:04 Gary Gregory wrote:
> Here is where we stand today:
> 
> - I fixed bugs where the JVM specification types data as "u2"
> (unsigned 2 bytes, range 0 to 65535) but we used to read these items
> as signed shorts so we "lost" values from 32768 to 65535 or we read
> them as negative values. Amazingly this did not cause tests to fail,
> which does not say much for our test coverage but these would be hard
> to find without specially crafted class files.
> - On Java8, the previously failing test
> VerifyJavaMathTestCase.testBigDecimal() passes but fails differently
> than it did when run on Java 11 or above. I only enabled the test on
> Java 8.
> - VerifyJavaUtilTestCase still fails to verify all its classes.
> - VerifyJavaHomesTestCase still has tons of failures
> 
> I might not hold up releasing 6.7.0 too long since these issues must
> have existed for a long time.
> 
> Gary
> 
> On Thu, Nov 17, 2022 at 10:53 AM Mark Roberts  
> wrote:
> >
> > I will try to take a look at this later today.
> >
> > Mark
> >
> > -Original Message-
> > From: Gary D. Gregory [mailto:ggreg...@apache.org]
> > Sent: Thursday, November 17, 2022 7:14 AM
> > To: dev@commons.apache.org
> > Subject: Re: [BCEL] Invalid test or bug?
> >
> > More specifically, javap says:
> >
> > 21: invokevirtual #68 // Method
> > "[B".clone:()Ljava/lang/Object;
> >
> > So calling a method on an array with invokevirtual is ok and we have a bug.
> >
> > Thoughts?
> >
> > Gary
> >
> > On 2022/11/17 14:45:41 "Gary D. Gregory" wrote:
> > > Hm, I'm thinking bug when I see javap output like:
> > >
> > > #68 = Methodref  #901.#902    //
> > > "[B".clone:()Ljava/lang/Object;
> > >
> > > Thoughts?
> > >
> > > Gary
> > >
> > > On 2022/11/17 13:04:32 "Gary D. Gregory" wrote:
> > > > Actually: VerifyJavaMathTestCase and VerifyJavaUtilTestCase
> > > >
> > > > Gary
> > > >
> > > > On 2022/11/17 13:00:21 "Gary D. Gregory" wrote:
> > > > > Hi All & Mark Roberts:
> > > > >
> > > > > I added JavaMathTestCase as a disabled test as it fails.
> > > > >
> > > > > Is this a legal test to try or do we have a bug?
> > > > >
> > > > > Gary
> > > > >
> > > > > --
> > > > > --- 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
> > >
> > >
> >
> > -
> > 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
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [BCEL] Invalid test or bug?

2022-11-17 Thread Gary D. Gregory
More specifically, javap says:

21: invokevirtual #68 // Method 
"[B".clone:()Ljava/lang/Object;

So calling a method on an array with invokevirtual is ok and we have a bug.

Thoughts?

Gary

On 2022/11/17 14:45:41 "Gary D. Gregory" wrote:
> Hm, I'm thinking bug when I see javap output like:
> 
> #68 = Methodref  #901.#902// "[B".clone:()Ljava/lang/Object;
> 
> Thoughts?
> 
> Gary
> 
> On 2022/11/17 13:04:32 "Gary D. Gregory" wrote:
> > Actually: VerifyJavaMathTestCase and VerifyJavaUtilTestCase
> > 
> > Gary
> > 
> > On 2022/11/17 13:00:21 "Gary D. Gregory" wrote:
> > > Hi All & Mark Roberts:
> > > 
> > > I added JavaMathTestCase as a disabled test as it fails.
> > > 
> > > Is this a legal test to try or do we have a bug?
> > > 
> > > Gary
> > > 
> > > -
> > > 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
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [BCEL] Invalid test or bug?

2022-11-17 Thread Gary D. Gregory
Hm, I'm thinking bug when I see javap output like:

#68 = Methodref  #901.#902// "[B".clone:()Ljava/lang/Object;

Thoughts?

Gary

On 2022/11/17 13:04:32 "Gary D. Gregory" wrote:
> Actually: VerifyJavaMathTestCase and VerifyJavaUtilTestCase
> 
> Gary
> 
> On 2022/11/17 13:00:21 "Gary D. Gregory" wrote:
> > Hi All & Mark Roberts:
> > 
> > I added JavaMathTestCase as a disabled test as it fails.
> > 
> > Is this a legal test to try or do we have a bug?
> > 
> > Gary
> > 
> > -
> > 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: [BCEL] Invalid test or bug?

2022-11-17 Thread Gary D. Gregory
Actually: VerifyJavaMathTestCase and VerifyJavaUtilTestCase

Gary

On 2022/11/17 13:00:21 "Gary D. Gregory" wrote:
> Hi All & Mark Roberts:
> 
> I added JavaMathTestCase as a disabled test as it fails.
> 
> Is this a legal test to try or do we have a bug?
> 
> Gary
> 
> -
> 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



[BCEL] Invalid test or bug?

2022-11-17 Thread Gary D. Gregory
Hi All & Mark Roberts:

I added JavaMathTestCase as a disabled test as it fails.

Is this a legal test to try or do we have a bug?

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [BCEL] low test coverage

2022-11-08 Thread Gary D. Gregory
Hello All,

Recent PRs have brought up the coverage to 52% as you can see from the badge on 
https://github.com/apache/commons-bcel pointing to 
https://app.codecov.io/gh/apache/commons-bcel/tree/master 

Thank you to those who pitched in.

You can also run 'mvn clean package site' locally and look at the JaCoCo report 
in target/site/ in the report section of the site.

I think the component could benefit from more tests. If anyone has apps that 
use BCEL that have bits that can be turned into tests, that would give us more 
real-world test cases.

TY,
Gary

On 2022/10/27 11:22:13 Gary Gregory wrote:
> BCEL currently stands at 44% code coverage from tests, which needs
> improvement obviously. Any help would be appreciated.
> 
> Gary
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



[collections] Using known concepts

2022-11-06 Thread Gary D. Gregory
We have:

org.apache.commons.collections4.bloomfilter.HasherCollection.add(Collection)

I propose that we rename it to "addAll" to follow existing Java concepts in 
Collections.

Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



CVE-2022-42920: Apache Commons BCEL prior to 6.6.0 allows producing arbitrary bytecode via out-of-bounds writing

2022-11-04 Thread Gary D. Gregory
Description:

Apache Commons BCEL has a number of APIs that would normally only allow 
changing specific class characteristics. However, due to an out-of-bounds 
writing issue, these APIs can be used to produce arbitrary bytecode. This could 
be abused in applications that pass attacker-controllable data to those APIs, 
giving the attacker more control over the resulting bytecode than otherwise 
expected. Update to Apache Commons BCEL 6.6.0.

This issue is being tracked as BCEL-363

Credit:

Reported by Felix Wilhelm (Google); GitHub pull request to Apache Commons BCEL 
#147 by Richard Atkins (https://github.com/rjatkins); PR derived from OpenJDK 
(https://github.com/openjdk/jdk11u/) commit 
13bf52c8d876528a43be7cb77a1f452d29a21492 by Aleksei Voitylov and RealCLanger 
(Christoph Langer https://github.com/RealCLanger)


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



RE: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC2

2022-11-02 Thread Gary D. Gregory
My +1

Gary

On 2022/11/02 18:58:26 "Gary D. Gregory" wrote:
> On 2022/11/02 16:41:30 Mark Roberts wrote:
> > In the constructor of
> > /src/main/java/org/apache/bcel/verifier/structurals/ExceptionHandlers.java -
> > the 'computeIfAbsent' line is duplicated.  Is this correct?
> 
> Good spot, luckily the semantics are the same (the key will be present on the 
> 2nd invocation); I'll fix it post-release.
> 
> Gary
>  
> > 
> > Mark
> > 
> > -Original Message-
> > From: Gary D. Gregory [mailto:ggreg...@apache.org]
> > Sent: Tuesday, November 1, 2022 10:17 AM
> > To: dev@commons.apache.org
> > Subject: Re: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC2
> > 
> > ping :-)
> > 
> > On 2022/10/29 16:35:28 Gary Gregory wrote:
> > > We have fixed a regression bug since Apache Commons BCEL 6.6.0 was
> > > released, so I would like to release Apache Commons BCEL 6.6.1.
> > >
> > > Apache Commons BCEL 6.6.1 RC2 is available for review here:
> > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2 (svn
> > > revision 57656)
> > >
> > > The Git tag commons-bcel-6.6.1-RC2 commit for this RC is
> > > eda94276de5d01c81e73ab2f165a49e841c7b69f which you can browse here:
> > >
> > > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=eda9
> > > 4276de5d01c81e73ab2f165a49e841c7b69f
> > > You may checkout this tag using:
> > > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> > > --branch
> > > commons-bcel-6.6.1-RC2 commons-bcel-6.6.1-RC2
> > >
> > > Maven artifacts are here:
> > >
> > > https://repository.apache.org/content/repositories/orgapachecommons-16
> > > 05/org/apache/bcel/bcel/6.6.1/
> > >
> > > These are the artifacts and their hashes:
> > >
> > > #Release SHA-512s
> > > #Sat Oct 29 12:22:19 EDT 2022
> > > Apache\ Commons\
> > > BCEL-6.6.1.spdx.rdf.xml=4f97b219f60290e0795999cf3c3483d2738dd429ca013f
> > > 764b20078a6f799200ff958a14cb4cc03c73f30b58836bf59229ce6ee4f5e94022df8b
> > > 533000946c84
> > > bcel-6.6.1-bin.tar.gz=7826733c3d139e52b6022d5df7430c391bd3b93707ef99f5
> > > 803390cb91f4ba0b87b073ca4e208869c5bd453f40739631ad8d6ab5ed3cbbc9270a5d
> > > c0345238f4
> > > bcel-6.6.1-bin.zip=d1c2fca54a5d5acc8edae097a7383dd56eb324a73f343da901b
> > > 0b1ea50b6a01910674e2f7f4497e8ac299fef25afb0060399c3aadbbabb879356f6fb0
> > > b4389ad
> > > bcel-6.6.1-bom.json=fb408f3f439fd0dcaef0ca6b2bf309bc6aac523096a12f7e5b
> > > af6374fa05f7d9f919b0ce520ceaf08b51960d8483f638d4e2ce5bd0994168786354bf
> > > 02866dd4
> > > bcel-6.6.1-bom.xml=7ef7417e5ef7f4443b4faba6cbc0c32b88522cf359d5de9a50e
> > > ad505070bb7ef779a18c9cad0aeaab6cf458f7c700ca3548a63f7d0a2804f73a527299
> > > 9f62855
> > > bcel-6.6.1-javadoc.jar=9a58c07addcb18f4a567418abf9e8d75e17ba6f05de0f95
> > > 6797890bfb4d1d8a8403d03f8cf947b4f48d9fc8c98276befb9fb2060e526dfd44e96e
> > > e3e755047e0
> > > bcel-6.6.1-sources.jar=6de8e778b0e82b3004c3d6041fa451ccf4a3a10ec61d1ff
> > > b1cf39287ea49440018d9d3ba06acad6de6e2b3cfd9d58737f5696ed8b20b3ba9ab5fd
> > > 642e7ae2aac
> > > bcel-6.6.1-src.tar.gz=d746bee8f0c3483fe589845a1a843043e6162970751e1e21
> > > a30f01f122556a1b9d52a8c7d808db91671f0f2324ff871ba5f571fc369bb77d232680
> > > 654cbb77b4
> > > bcel-6.6.1-src.zip=6759324529a42e45ffdd449cddf01dade57459b86a4820550d5
> > > a859ff1eca85057a9343ae217def029d9f8e4b3365b49f692522a2e75cd1dc4806b8f9
> > > 09c613a
> > > bcel-6.6.1-test-sources.jar=604df990454feb5976b9f0b763bdbd50a434bb1db2
> > > 6d9876a555195ca42d99a3b6b84b2718ac925896a9bb2c05f0633d4cb275fe69574183
> > > 6fe9aa0cb18d4db3
> > > bcel-6.6.1-tests.jar=0f1b1396d376cc0f2c69e897817b0a7b24db282cf7122d895
> > > dabe70aa1b7d0faf4348cae4cb01e4d93224552f4db77fdd86af11c69574635b282e74
> > > b451a689e
> > >
> > >
> > > I have tested this with 'mvn -V -Duser.name=$my_apache_id -Prelease
> > > -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
> > >
> > > Darwin  21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10
> > > PDT 2022; root:xnu-8020.140.49~2/RELEASE_X86_64 x86_64 Apache Maven
> > > 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > > Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> > > Java version: 1.8.0_345, vendor: Homebrew, runtime:
> > > /usr/local/Cellar/openjdk@8/1.8.0+345/libexec/openjdk.jdk/

RE: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC2

2022-11-02 Thread Gary D. Gregory
On 2022/11/02 16:41:30 Mark Roberts wrote:
> In the constructor of
> /src/main/java/org/apache/bcel/verifier/structurals/ExceptionHandlers.java -
> the 'computeIfAbsent' line is duplicated.  Is this correct?

Good spot, luckily the semantics are the same (the key will be present on the 
2nd invocation); I'll fix it post-release.

Gary
 
> 
> Mark
> 
> -Original Message-
> From: Gary D. Gregory [mailto:ggreg...@apache.org]
> Sent: Tuesday, November 1, 2022 10:17 AM
> To: dev@commons.apache.org
> Subject: Re: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC2
> 
> ping :-)
> 
> On 2022/10/29 16:35:28 Gary Gregory wrote:
> > We have fixed a regression bug since Apache Commons BCEL 6.6.0 was
> > released, so I would like to release Apache Commons BCEL 6.6.1.
> >
> > Apache Commons BCEL 6.6.1 RC2 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2 (svn
> > revision 57656)
> >
> > The Git tag commons-bcel-6.6.1-RC2 commit for this RC is
> > eda94276de5d01c81e73ab2f165a49e841c7b69f which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=eda9
> > 4276de5d01c81e73ab2f165a49e841c7b69f
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> > --branch
> > commons-bcel-6.6.1-RC2 commons-bcel-6.6.1-RC2
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-16
> > 05/org/apache/bcel/bcel/6.6.1/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Sat Oct 29 12:22:19 EDT 2022
> > Apache\ Commons\
> > BCEL-6.6.1.spdx.rdf.xml=4f97b219f60290e0795999cf3c3483d2738dd429ca013f
> > 764b20078a6f799200ff958a14cb4cc03c73f30b58836bf59229ce6ee4f5e94022df8b
> > 533000946c84
> > bcel-6.6.1-bin.tar.gz=7826733c3d139e52b6022d5df7430c391bd3b93707ef99f5
> > 803390cb91f4ba0b87b073ca4e208869c5bd453f40739631ad8d6ab5ed3cbbc9270a5d
> > c0345238f4
> > bcel-6.6.1-bin.zip=d1c2fca54a5d5acc8edae097a7383dd56eb324a73f343da901b
> > 0b1ea50b6a01910674e2f7f4497e8ac299fef25afb0060399c3aadbbabb879356f6fb0
> > b4389ad
> > bcel-6.6.1-bom.json=fb408f3f439fd0dcaef0ca6b2bf309bc6aac523096a12f7e5b
> > af6374fa05f7d9f919b0ce520ceaf08b51960d8483f638d4e2ce5bd0994168786354bf
> > 02866dd4
> > bcel-6.6.1-bom.xml=7ef7417e5ef7f4443b4faba6cbc0c32b88522cf359d5de9a50e
> > ad505070bb7ef779a18c9cad0aeaab6cf458f7c700ca3548a63f7d0a2804f73a527299
> > 9f62855
> > bcel-6.6.1-javadoc.jar=9a58c07addcb18f4a567418abf9e8d75e17ba6f05de0f95
> > 6797890bfb4d1d8a8403d03f8cf947b4f48d9fc8c98276befb9fb2060e526dfd44e96e
> > e3e755047e0
> > bcel-6.6.1-sources.jar=6de8e778b0e82b3004c3d6041fa451ccf4a3a10ec61d1ff
> > b1cf39287ea49440018d9d3ba06acad6de6e2b3cfd9d58737f5696ed8b20b3ba9ab5fd
> > 642e7ae2aac
> > bcel-6.6.1-src.tar.gz=d746bee8f0c3483fe589845a1a843043e6162970751e1e21
> > a30f01f122556a1b9d52a8c7d808db91671f0f2324ff871ba5f571fc369bb77d232680
> > 654cbb77b4
> > bcel-6.6.1-src.zip=6759324529a42e45ffdd449cddf01dade57459b86a4820550d5
> > a859ff1eca85057a9343ae217def029d9f8e4b3365b49f692522a2e75cd1dc4806b8f9
> > 09c613a
> > bcel-6.6.1-test-sources.jar=604df990454feb5976b9f0b763bdbd50a434bb1db2
> > 6d9876a555195ca42d99a3b6b84b2718ac925896a9bb2c05f0633d4cb275fe69574183
> > 6fe9aa0cb18d4db3
> > bcel-6.6.1-tests.jar=0f1b1396d376cc0f2c69e897817b0a7b24db282cf7122d895
> > dabe70aa1b7d0faf4348cae4cb01e4d93224552f4db77fdd86af11c69574635b282e74
> > b451a689e
> >
> >
> > I have tested this with 'mvn -V -Duser.name=$my_apache_id -Prelease
> > -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
> >
> > Darwin  21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10
> > PDT 2022; root:xnu-8020.140.49~2/RELEASE_X86_64 x86_64 Apache Maven
> > 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> > Java version: 1.8.0_345, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@8/1.8.0+345/libexec/openjdk.jdk/Contents/Hom
> > e/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os
> > x", version: "12.6", arch: "x86_64", family: "mac"
> >
> > Details of changes since 6.6.0 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/RELEASE-
> > NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/site/cha
> > nges-report.html
> >
> > Site:
> >
>

Re: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC2

2022-11-02 Thread Gary D. Gregory
I updated git master for consistency to use the URL that does not redirect.

On 2022/11/02 14:42:05 "Gary D. Gregory" wrote:
> Note that https://commons.apache.org/bcel redirects to 
> https://commons.apache.org/proper/commons-bcel
> 
> On 2022/11/02 14:15:44 Alex Herbert wrote:
> > Validated signatures using
> > 
> > svn co https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2
> > cd 6.6.1-RC2/
> > chmod +x signature-validator.sh
> > ./signature-validator.sh
> > https://repository.apache.org/content/repositories/orgapachecommons-1605/org/apache/bcel/bcel/6.6.1/
> > 
> > Built from the source tar using 'mvn install site':
> > 
> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > Maven home: /usr/local/apache-maven-3
> > Java version: 11.0.16, vendor: Ubuntu, runtime:
> > /usr/lib/jvm/java-11-openjdk-amd64
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "linux", version: "4.15.0-194-generic", arch: "amd64", family: 
> > "unix"
> > 
> > Release notes:
> > 
> > Contains some help about feedback with this link:
> > 
> > https://commons.apache.org/bcel
> > 
> > But a few lines above there is the correct link:
> > 
> > https://commons.apache.org/proper/commons-bcel
> > 
> > The Feedback section seems redundant given the boiler plate text above it.
> > 
> > 
> > Checked all the reports. SpotBugs has a few but PMD is now clean.
> > 
> > 
> > JApiCmp
> > 
> > New method: org.apache.bcel.verifier.PassVerifier.getMessageList() has
> > no @Since tag and no documented @return tag.
> > 
> > A recent change to remove all the initialisation in the inner class
> > org.apache.bcel.generic.InstructionConstants$Clinit constructor has
> > removed the formally package-private constructor. The default
> > constructor is now public. This is not a breaking change but I do not
> > think it was intended to expose this. I think it should have been left
> > as:
> > 
> > class Clinit {
> > Clinit() {
> > // Intentionally empty
> > }
> > }
> > 
> > 
> > Alex
> > 
> > On Sat, 29 Oct 2022 at 17:35, Gary Gregory  wrote:
> > >
> > > We have fixed a regression bug since Apache Commons BCEL 6.6.0 was
> > > released, so I would like to release Apache Commons BCEL 6.6.1.
> > >
> > > Apache Commons BCEL 6.6.1 RC2 is available for review here:
> > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2 (svn
> > > revision 57656)
> > >
> > > The Git tag commons-bcel-6.6.1-RC2 commit for this RC is
> > > eda94276de5d01c81e73ab2f165a49e841c7b69f which you can browse here:
> > >
> > > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=eda94276de5d01c81e73ab2f165a49e841c7b69f
> > > You may checkout this tag using:
> > > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git 
> > > --branch
> > > commons-bcel-6.6.1-RC2 commons-bcel-6.6.1-RC2
> > >
> > > Maven artifacts are here:
> > >
> > > https://repository.apache.org/content/repositories/orgapachecommons-1605/org/apache/bcel/bcel/6.6.1/
> > >
> > > These are the artifacts and their hashes:
> > >
> > > #Release SHA-512s
> > > #Sat Oct 29 12:22:19 EDT 2022
> > > Apache\ Commons\
> > > BCEL-6.6.1.spdx.rdf.xml=4f97b219f60290e0795999cf3c3483d2738dd429ca013f764b20078a6f799200ff958a14cb4cc03c73f30b58836bf59229ce6ee4f5e94022df8b533000946c84
> > > bcel-6.6.1-bin.tar.gz=7826733c3d139e52b6022d5df7430c391bd3b93707ef99f5803390cb91f4ba0b87b073ca4e208869c5bd453f40739631ad8d6ab5ed3cbbc9270a5dc0345238f4
> > > bcel-6.6.1-bin.zip=d1c2fca54a5d5acc8edae097a7383dd56eb324a73f343da901b0b1ea50b6a01910674e2f7f4497e8ac299fef25afb0060399c3aadbbabb879356f6fb0b4389ad
> > > bcel-6.6.1-bom.json=fb408f3f439fd0dcaef0ca6b2bf309bc6aac523096a12f7e5baf6374fa05f7d9f919b0ce520ceaf08b51960d8483f638d4e2ce5bd0994168786354bf02866dd4
> > > bcel-6.6.1-bom.xml=7ef7417e5ef7f4443b4faba6cbc0c32b88522cf359d5de9a50ead505070bb7ef779a18c9cad0aeaab6cf458f7c700ca3548a63f7d0a2804f73a5272999f62855
> > > bcel-6.6.1-javadoc.jar=9a58c07addcb18f4a567418abf9e8d75e17ba6f05de0f956797890bfb4d1d8a8403d03f8cf947b4f48d9fc8c98276befb9fb2060e526dfd44e96ee3e755047e0
> > > bcel-6.6.1-sources.jar=6de8e778b0e82b3004c3d6041fa451ccf4a3a10ec61d1ffb1cf39287ea49440018d9d3ba06acad6de6e2b3cfd9d58737f5696ed8b20b3ba9ab5fd642e7ae2aac
> > > bcel-6.6.1-src.tar.gz=d746bee8f0c34

Re: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC2

2022-11-02 Thread Gary D. Gregory
Note that https://commons.apache.org/bcel redirects to 
https://commons.apache.org/proper/commons-bcel

On 2022/11/02 14:15:44 Alex Herbert wrote:
> Validated signatures using
> 
> svn co https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2
> cd 6.6.1-RC2/
> chmod +x signature-validator.sh
> ./signature-validator.sh
> https://repository.apache.org/content/repositories/orgapachecommons-1605/org/apache/bcel/bcel/6.6.1/
> 
> Built from the source tar using 'mvn install site':
> 
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/apache-maven-3
> Java version: 11.0.16, vendor: Ubuntu, runtime:
> /usr/lib/jvm/java-11-openjdk-amd64
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-194-generic", arch: "amd64", family: "unix"
> 
> Release notes:
> 
> Contains some help about feedback with this link:
> 
> https://commons.apache.org/bcel
> 
> But a few lines above there is the correct link:
> 
> https://commons.apache.org/proper/commons-bcel
> 
> The Feedback section seems redundant given the boiler plate text above it.
> 
> 
> Checked all the reports. SpotBugs has a few but PMD is now clean.
> 
> 
> JApiCmp
> 
> New method: org.apache.bcel.verifier.PassVerifier.getMessageList() has
> no @Since tag and no documented @return tag.
> 
> A recent change to remove all the initialisation in the inner class
> org.apache.bcel.generic.InstructionConstants$Clinit constructor has
> removed the formally package-private constructor. The default
> constructor is now public. This is not a breaking change but I do not
> think it was intended to expose this. I think it should have been left
> as:
> 
> class Clinit {
> Clinit() {
> // Intentionally empty
> }
> }
> 
> 
> Alex
> 
> On Sat, 29 Oct 2022 at 17:35, Gary Gregory  wrote:
> >
> > We have fixed a regression bug since Apache Commons BCEL 6.6.0 was
> > released, so I would like to release Apache Commons BCEL 6.6.1.
> >
> > Apache Commons BCEL 6.6.1 RC2 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2 (svn
> > revision 57656)
> >
> > The Git tag commons-bcel-6.6.1-RC2 commit for this RC is
> > eda94276de5d01c81e73ab2f165a49e841c7b69f which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=eda94276de5d01c81e73ab2f165a49e841c7b69f
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git --branch
> > commons-bcel-6.6.1-RC2 commons-bcel-6.6.1-RC2
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1605/org/apache/bcel/bcel/6.6.1/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Sat Oct 29 12:22:19 EDT 2022
> > Apache\ Commons\
> > BCEL-6.6.1.spdx.rdf.xml=4f97b219f60290e0795999cf3c3483d2738dd429ca013f764b20078a6f799200ff958a14cb4cc03c73f30b58836bf59229ce6ee4f5e94022df8b533000946c84
> > bcel-6.6.1-bin.tar.gz=7826733c3d139e52b6022d5df7430c391bd3b93707ef99f5803390cb91f4ba0b87b073ca4e208869c5bd453f40739631ad8d6ab5ed3cbbc9270a5dc0345238f4
> > bcel-6.6.1-bin.zip=d1c2fca54a5d5acc8edae097a7383dd56eb324a73f343da901b0b1ea50b6a01910674e2f7f4497e8ac299fef25afb0060399c3aadbbabb879356f6fb0b4389ad
> > bcel-6.6.1-bom.json=fb408f3f439fd0dcaef0ca6b2bf309bc6aac523096a12f7e5baf6374fa05f7d9f919b0ce520ceaf08b51960d8483f638d4e2ce5bd0994168786354bf02866dd4
> > bcel-6.6.1-bom.xml=7ef7417e5ef7f4443b4faba6cbc0c32b88522cf359d5de9a50ead505070bb7ef779a18c9cad0aeaab6cf458f7c700ca3548a63f7d0a2804f73a5272999f62855
> > bcel-6.6.1-javadoc.jar=9a58c07addcb18f4a567418abf9e8d75e17ba6f05de0f956797890bfb4d1d8a8403d03f8cf947b4f48d9fc8c98276befb9fb2060e526dfd44e96ee3e755047e0
> > bcel-6.6.1-sources.jar=6de8e778b0e82b3004c3d6041fa451ccf4a3a10ec61d1ffb1cf39287ea49440018d9d3ba06acad6de6e2b3cfd9d58737f5696ed8b20b3ba9ab5fd642e7ae2aac
> > bcel-6.6.1-src.tar.gz=d746bee8f0c3483fe589845a1a843043e6162970751e1e21a30f01f122556a1b9d52a8c7d808db91671f0f2324ff871ba5f571fc369bb77d232680654cbb77b4
> > bcel-6.6.1-src.zip=6759324529a42e45ffdd449cddf01dade57459b86a4820550d5a859ff1eca85057a9343ae217def029d9f8e4b3365b49f692522a2e75cd1dc4806b8f909c613a
> > bcel-6.6.1-test-sources.jar=604df990454feb5976b9f0b763bdbd50a434bb1db26d9876a555195ca42d99a3b6b84b2718ac925896a9bb2c05f0633d4cb275fe695741836fe9aa0cb18d4db3
> > bcel-6.6.1-tests.jar=0f1b1396d376cc0f2c69e897817b0a7b24db282cf7122d895dabe70aa1b7d0faf4348cae4cb01e4d93224552f4db77fdd86af11c69574635b282e74b451a689e
> >
> >
> > I have tested this with 'mvn -V -Duser.name=$my_apache_id -Prelease
> > -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
> >
> > Darwin  21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10 PDT
> > 2022; root:xnu-8020.140.49~2/RELEASE_X86_64 x86_64
> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> > Java version: 1.8.0_345, 

Re: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC2

2022-11-02 Thread Gary D. Gregory
Thank you for the review, my comments are inline below.

On 2022/11/02 14:15:44 Alex Herbert wrote:
> Validated signatures using
> 
> svn co https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2
> cd 6.6.1-RC2/
> chmod +x signature-validator.sh
> ./signature-validator.sh
> https://repository.apache.org/content/repositories/orgapachecommons-1605/org/apache/bcel/bcel/6.6.1/
> 
> Built from the source tar using 'mvn install site':
> 
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/apache-maven-3
> Java version: 11.0.16, vendor: Ubuntu, runtime:
> /usr/lib/jvm/java-11-openjdk-amd64
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-194-generic", arch: "amd64", family: "unix"
> 
> Release notes:
> 
> Contains some help about feedback with this link:
> 
> https://commons.apache.org/bcel
> 
> But a few lines above there is the correct link:
> 
> https://commons.apache.org/proper/commons-bcel
> 
> The Feedback section seems redundant given the boiler plate text above it.

I can clean that up after a release of course.

> 
> 
> Checked all the reports. SpotBugs has a few but PMD is now clean.

Some SpotBugs issues might not be fixable without breaking BC. No deal breakers 
IMO. More like TODOs.

> 
> 
> JApiCmp
> 
> New method: org.apache.bcel.verifier.PassVerifier.getMessageList() has
> no @Since tag and no documented @return tag.
> 
> A recent change to remove all the initialisation in the inner class
> org.apache.bcel.generic.InstructionConstants$Clinit constructor has
> removed the formally package-private constructor. The default
> constructor is now public. This is not a breaking change but I do not
> think it was intended to expose this. I think it should have been left
> as:
> 
> class Clinit {
> Clinit() {
> // Intentionally empty
> }
> }

Good find indeed. Do you think this requires another release candidate since 
this new public item is in a deprecated class? And does nothing.

TY!
Gary

> 
> 
> Alex
> 
> On Sat, 29 Oct 2022 at 17:35, Gary Gregory  wrote:
> >
> > We have fixed a regression bug since Apache Commons BCEL 6.6.0 was
> > released, so I would like to release Apache Commons BCEL 6.6.1.
> >
> > Apache Commons BCEL 6.6.1 RC2 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2 (svn
> > revision 57656)
> >
> > The Git tag commons-bcel-6.6.1-RC2 commit for this RC is
> > eda94276de5d01c81e73ab2f165a49e841c7b69f which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=eda94276de5d01c81e73ab2f165a49e841c7b69f
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git --branch
> > commons-bcel-6.6.1-RC2 commons-bcel-6.6.1-RC2
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1605/org/apache/bcel/bcel/6.6.1/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Sat Oct 29 12:22:19 EDT 2022
> > Apache\ Commons\
> > BCEL-6.6.1.spdx.rdf.xml=4f97b219f60290e0795999cf3c3483d2738dd429ca013f764b20078a6f799200ff958a14cb4cc03c73f30b58836bf59229ce6ee4f5e94022df8b533000946c84
> > bcel-6.6.1-bin.tar.gz=7826733c3d139e52b6022d5df7430c391bd3b93707ef99f5803390cb91f4ba0b87b073ca4e208869c5bd453f40739631ad8d6ab5ed3cbbc9270a5dc0345238f4
> > bcel-6.6.1-bin.zip=d1c2fca54a5d5acc8edae097a7383dd56eb324a73f343da901b0b1ea50b6a01910674e2f7f4497e8ac299fef25afb0060399c3aadbbabb879356f6fb0b4389ad
> > bcel-6.6.1-bom.json=fb408f3f439fd0dcaef0ca6b2bf309bc6aac523096a12f7e5baf6374fa05f7d9f919b0ce520ceaf08b51960d8483f638d4e2ce5bd0994168786354bf02866dd4
> > bcel-6.6.1-bom.xml=7ef7417e5ef7f4443b4faba6cbc0c32b88522cf359d5de9a50ead505070bb7ef779a18c9cad0aeaab6cf458f7c700ca3548a63f7d0a2804f73a5272999f62855
> > bcel-6.6.1-javadoc.jar=9a58c07addcb18f4a567418abf9e8d75e17ba6f05de0f956797890bfb4d1d8a8403d03f8cf947b4f48d9fc8c98276befb9fb2060e526dfd44e96ee3e755047e0
> > bcel-6.6.1-sources.jar=6de8e778b0e82b3004c3d6041fa451ccf4a3a10ec61d1ffb1cf39287ea49440018d9d3ba06acad6de6e2b3cfd9d58737f5696ed8b20b3ba9ab5fd642e7ae2aac
> > bcel-6.6.1-src.tar.gz=d746bee8f0c3483fe589845a1a843043e6162970751e1e21a30f01f122556a1b9d52a8c7d808db91671f0f2324ff871ba5f571fc369bb77d232680654cbb77b4
> > bcel-6.6.1-src.zip=6759324529a42e45ffdd449cddf01dade57459b86a4820550d5a859ff1eca85057a9343ae217def029d9f8e4b3365b49f692522a2e75cd1dc4806b8f909c613a
> > bcel-6.6.1-test-sources.jar=604df990454feb5976b9f0b763bdbd50a434bb1db26d9876a555195ca42d99a3b6b84b2718ac925896a9bb2c05f0633d4cb275fe695741836fe9aa0cb18d4db3
> > bcel-6.6.1-tests.jar=0f1b1396d376cc0f2c69e897817b0a7b24db282cf7122d895dabe70aa1b7d0faf4348cae4cb01e4d93224552f4db77fdd86af11c69574635b282e74b451a689e
> >
> >
> > I have tested this with 'mvn -V -Duser.name=$my_apache_id -Prelease
> > -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
> >
> > Darwin  21.6.0 

Re: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC2

2022-11-02 Thread Gary D. Gregory
pong?

On 2022/11/01 17:16:57 "Gary D. Gregory" wrote:
> ping :-)
> 
> On 2022/10/29 16:35:28 Gary Gregory wrote:
> > We have fixed a regression bug since Apache Commons BCEL 6.6.0 was
> > released, so I would like to release Apache Commons BCEL 6.6.1.
> > 
> > Apache Commons BCEL 6.6.1 RC2 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2 (svn
> > revision 57656)
> > 
> > The Git tag commons-bcel-6.6.1-RC2 commit for this RC is
> > eda94276de5d01c81e73ab2f165a49e841c7b69f which you can browse here:
> > 
> > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=eda94276de5d01c81e73ab2f165a49e841c7b69f
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git --branch
> > commons-bcel-6.6.1-RC2 commons-bcel-6.6.1-RC2
> > 
> > Maven artifacts are here:
> > 
> > https://repository.apache.org/content/repositories/orgapachecommons-1605/org/apache/bcel/bcel/6.6.1/
> > 
> > These are the artifacts and their hashes:
> > 
> > #Release SHA-512s
> > #Sat Oct 29 12:22:19 EDT 2022
> > Apache\ Commons\
> > BCEL-6.6.1.spdx.rdf.xml=4f97b219f60290e0795999cf3c3483d2738dd429ca013f764b20078a6f799200ff958a14cb4cc03c73f30b58836bf59229ce6ee4f5e94022df8b533000946c84
> > bcel-6.6.1-bin.tar.gz=7826733c3d139e52b6022d5df7430c391bd3b93707ef99f5803390cb91f4ba0b87b073ca4e208869c5bd453f40739631ad8d6ab5ed3cbbc9270a5dc0345238f4
> > bcel-6.6.1-bin.zip=d1c2fca54a5d5acc8edae097a7383dd56eb324a73f343da901b0b1ea50b6a01910674e2f7f4497e8ac299fef25afb0060399c3aadbbabb879356f6fb0b4389ad
> > bcel-6.6.1-bom.json=fb408f3f439fd0dcaef0ca6b2bf309bc6aac523096a12f7e5baf6374fa05f7d9f919b0ce520ceaf08b51960d8483f638d4e2ce5bd0994168786354bf02866dd4
> > bcel-6.6.1-bom.xml=7ef7417e5ef7f4443b4faba6cbc0c32b88522cf359d5de9a50ead505070bb7ef779a18c9cad0aeaab6cf458f7c700ca3548a63f7d0a2804f73a5272999f62855
> > bcel-6.6.1-javadoc.jar=9a58c07addcb18f4a567418abf9e8d75e17ba6f05de0f956797890bfb4d1d8a8403d03f8cf947b4f48d9fc8c98276befb9fb2060e526dfd44e96ee3e755047e0
> > bcel-6.6.1-sources.jar=6de8e778b0e82b3004c3d6041fa451ccf4a3a10ec61d1ffb1cf39287ea49440018d9d3ba06acad6de6e2b3cfd9d58737f5696ed8b20b3ba9ab5fd642e7ae2aac
> > bcel-6.6.1-src.tar.gz=d746bee8f0c3483fe589845a1a843043e6162970751e1e21a30f01f122556a1b9d52a8c7d808db91671f0f2324ff871ba5f571fc369bb77d232680654cbb77b4
> > bcel-6.6.1-src.zip=6759324529a42e45ffdd449cddf01dade57459b86a4820550d5a859ff1eca85057a9343ae217def029d9f8e4b3365b49f692522a2e75cd1dc4806b8f909c613a
> > bcel-6.6.1-test-sources.jar=604df990454feb5976b9f0b763bdbd50a434bb1db26d9876a555195ca42d99a3b6b84b2718ac925896a9bb2c05f0633d4cb275fe695741836fe9aa0cb18d4db3
> > bcel-6.6.1-tests.jar=0f1b1396d376cc0f2c69e897817b0a7b24db282cf7122d895dabe70aa1b7d0faf4348cae4cb01e4d93224552f4db77fdd86af11c69574635b282e74b451a689e
> > 
> > 
> > I have tested this with 'mvn -V -Duser.name=$my_apache_id -Prelease
> > -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
> > 
> > Darwin  21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10 PDT
> > 2022; root:xnu-8020.140.49~2/RELEASE_X86_64 x86_64
> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> > Java version: 1.8.0_345, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@8/1.8.0+345/libexec/openjdk.jdk/Contents/Home/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "12.6", arch: "x86_64", family: "mac"
> > 
> > Details of changes since 6.6.0 are in the release notes:
> > 
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/RELEASE-NOTES.txt
> > 
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/site/changes-report.html
> > 
> > Site:
> > 
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/site/index.html
> > (note some *relative* links are broken and the 6.6.1 directories are
> > not yet created - these will be OK once the site is deployed.)
> > 
> > JApiCmp Report (compared to 6.6.0):
> > 
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/site/japicmp.html
> > 
> > RAT Report:
> > 
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/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, b

Re: ENMT VALIDATION RESULTS

2022-11-01 Thread Gary D. Gregory
It seems to me the first step would be to contact whomever wrote 
org.onap.portalsdk.analytics.model.runtime.ReportRuntime

Gary

On 2022/11/01 23:46:17 Scott Short wrote:
> Hello,
> 
> I received the following error when trying to view Validation Results in 
> ENMT. Please advise.
> 
> 
> 
> 
> Error
> java.lang.IllegalStateException: Entry.next=null, data[removeIndex]=null 
> previous=null key=30507 
> value=org.onap.portalsdk.analytics.model.runtime.ReportRuntime@16903d38 
> size=100 maxSize=100 Please check that your keys are immutable, and that you 
> have used synchronization properly. If so, then please report this to 
> dev@commons.apache.org as a bug.
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



Re: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC2

2022-11-01 Thread Gary D. Gregory
ping :-)

On 2022/10/29 16:35:28 Gary Gregory wrote:
> We have fixed a regression bug since Apache Commons BCEL 6.6.0 was
> released, so I would like to release Apache Commons BCEL 6.6.1.
> 
> Apache Commons BCEL 6.6.1 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2 (svn
> revision 57656)
> 
> The Git tag commons-bcel-6.6.1-RC2 commit for this RC is
> eda94276de5d01c81e73ab2f165a49e841c7b69f which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=eda94276de5d01c81e73ab2f165a49e841c7b69f
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-bcel.git --branch
> commons-bcel-6.6.1-RC2 commons-bcel-6.6.1-RC2
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1605/org/apache/bcel/bcel/6.6.1/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Sat Oct 29 12:22:19 EDT 2022
> Apache\ Commons\
> BCEL-6.6.1.spdx.rdf.xml=4f97b219f60290e0795999cf3c3483d2738dd429ca013f764b20078a6f799200ff958a14cb4cc03c73f30b58836bf59229ce6ee4f5e94022df8b533000946c84
> bcel-6.6.1-bin.tar.gz=7826733c3d139e52b6022d5df7430c391bd3b93707ef99f5803390cb91f4ba0b87b073ca4e208869c5bd453f40739631ad8d6ab5ed3cbbc9270a5dc0345238f4
> bcel-6.6.1-bin.zip=d1c2fca54a5d5acc8edae097a7383dd56eb324a73f343da901b0b1ea50b6a01910674e2f7f4497e8ac299fef25afb0060399c3aadbbabb879356f6fb0b4389ad
> bcel-6.6.1-bom.json=fb408f3f439fd0dcaef0ca6b2bf309bc6aac523096a12f7e5baf6374fa05f7d9f919b0ce520ceaf08b51960d8483f638d4e2ce5bd0994168786354bf02866dd4
> bcel-6.6.1-bom.xml=7ef7417e5ef7f4443b4faba6cbc0c32b88522cf359d5de9a50ead505070bb7ef779a18c9cad0aeaab6cf458f7c700ca3548a63f7d0a2804f73a5272999f62855
> bcel-6.6.1-javadoc.jar=9a58c07addcb18f4a567418abf9e8d75e17ba6f05de0f956797890bfb4d1d8a8403d03f8cf947b4f48d9fc8c98276befb9fb2060e526dfd44e96ee3e755047e0
> bcel-6.6.1-sources.jar=6de8e778b0e82b3004c3d6041fa451ccf4a3a10ec61d1ffb1cf39287ea49440018d9d3ba06acad6de6e2b3cfd9d58737f5696ed8b20b3ba9ab5fd642e7ae2aac
> bcel-6.6.1-src.tar.gz=d746bee8f0c3483fe589845a1a843043e6162970751e1e21a30f01f122556a1b9d52a8c7d808db91671f0f2324ff871ba5f571fc369bb77d232680654cbb77b4
> bcel-6.6.1-src.zip=6759324529a42e45ffdd449cddf01dade57459b86a4820550d5a859ff1eca85057a9343ae217def029d9f8e4b3365b49f692522a2e75cd1dc4806b8f909c613a
> bcel-6.6.1-test-sources.jar=604df990454feb5976b9f0b763bdbd50a434bb1db26d9876a555195ca42d99a3b6b84b2718ac925896a9bb2c05f0633d4cb275fe695741836fe9aa0cb18d4db3
> bcel-6.6.1-tests.jar=0f1b1396d376cc0f2c69e897817b0a7b24db282cf7122d895dabe70aa1b7d0faf4348cae4cb01e4d93224552f4db77fdd86af11c69574635b282e74b451a689e
> 
> 
> I have tested this with 'mvn -V -Duser.name=$my_apache_id -Prelease
> -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
> 
> Darwin  21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10 PDT
> 2022; root:xnu-8020.140.49~2/RELEASE_X86_64 x86_64
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> Java version: 1.8.0_345, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8/1.8.0+345/libexec/openjdk.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.6", arch: "x86_64", family: "mac"
> 
> Details of changes since 6.6.0 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/site/changes-report.html
> 
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/site/index.html
> (note some *relative* links are broken and the 6.6.1 directories are
> not yet created - these will be OK once the site is deployed.)
> 
> JApiCmp Report (compared to 6.6.0):
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/site/japicmp.html
> 
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/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.
> 
> 1) Clone and checkout the RC tag
> 
> git clone https://gitbox.apache.org/repos/asf/commons-bcel.git --branch
> commons-bcel-6.6.1-RC2 commons-bcel-6.6.1-RC2
> cd commons-bcel-6.6.1-RC2
> 
> 2) Check Apache licenses
> 
> This step is not required if the site includes 

Re: [numbers] Erronous tag NUMBERS_1_0_B1_RC1

2022-10-30 Thread Gary D. Gregory
There better never be RC tags under the rel/ prefix, that space is only for 
releases and lives forever.

Gary

On 2022/10/28 16:38:24 Alex Herbert wrote:
> When preparing the 1.1 RC for [numbers] I pushed my tags using:
> 
> git push --tags
> 
> This seems to have pushed an old tag NUMBERS_1_0_B1_RC1 made by Matt
> Juntunen a few days before the official beta RC1 tag. This is pointing
> at a different commit from the tags used for the beta release:
> 
> commons-numbers-1.0-beta1-rc1
> rel/commons-numbers-1.0-beta1-rc1
> 
> ---
> > git tag -v commons-numbers-1.0-beta1-rc1
> object 3406c0980b4bc1071314bbb081dad2ef49cd68d3
> type commit
> tag commons-numbers-1.0-beta1-rc1
> tagger Matt Juntunen  1585912799 -0400
> 
> 1.0-beta1-rc1
> gpg: Signature made Fri 03 Apr 2020 12:19:59 BST
> gpg:using RSA key 7DD53AEFEDF1C3D392B51EBE346F4FCECFB70B1A
> gpg:issuer "mattjuntu...@apache.org"
> gpg: Can't check signature: No public key
> 
> > git tag -v NUMBERS_1_0_B1_RC1
> object 38730f37233053ec411312f5cc8afe9214bb7942
> type commit
> tag NUMBERS_1_0_B1_RC1
> tagger Matt Juntunen  1585513554 -0400
> 
> RC1
> gpg: Signature made Sun 29 Mar 2020 21:25:54 BST
> gpg:using RSA key 7DD53AEFEDF1C3D392B51EBE346F4FCECFB70B1A
> gpg:issuer "mattjuntu...@apache.org"
> gpg: Can't check signature: No public key
> ---
> 
> I suggest we remove this tag from the repository given it was not used
> for any published release or release candidate.
> 
> Alex
> 
> -
> 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 Compress 1.22 based on RC1

2022-10-30 Thread Gary D. Gregory
What is happening with this vote thread?

Gary

On 2022/10/28 20:02:21 Bruno Kinoshita wrote:
> Hi Matt,
> 
>   [x] +1 Release these artifacts
> 
> Thanks for confirming the tag name.
> 
> Build passing successfully using that tag, running `mvn clean test install
> site` on
> 
> nothing to commit, working tree clean
> kinow@ranma:~/Development/java/apache/commons-compress$ mvn -v
> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> Maven home: /opt/apache-maven-3.8.5
> Java version: 17.0.4, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-52-generic", arch: "amd64", family:
> "unix"
> 
> The site's changes.xml generated HTML page does not have a description
> (other releases have), and shows as not released yet (normally it has the
> vote release date, I think). Can be fixed later, other reports look OK.
> 
> Manually inspected files from dist area (source and binaries), and also
> checked signatures. Everything looks OK!
> 
> Thanks Matt,
> Bruno
> 
> On Sat, 29 Oct 2022 at 05:26, Matt Sicker  wrote:
> 
> > The branch release-1.22 is where I’m staging the release before merging
> > back to master. The tag was accidentally named “commons-compress-1.22”
> > which I aliased to the RC1 tag, but it appears I might not have pushed the
> > second tag. I’ll fix the tag later today, though in the meantime, you can
> > use the same tag without “-RC1” appended.
> >
> > > On Oct 27, 2022, at 9:38 PM, Bruno Kinoshita  wrote:
> > >
> > > Hi Matt,
> > >
> > > 1) Clone and checkout the RC tag
> > >>
> > >> git clone https://gitbox.apache.org/repos/asf/commons-compress.git
> > >> --branch commons-compress-1.22-RC1 commons-compress-1.22-RC1
> > >> cd commons-compress-1.22-RC1
> > >>
> > >
> > > Tried checking it out after `git fetch --all --tags`, but found nothing.
> > > Opened gitbox and the closest I found was a tag without the RC1. I think
> > > there's also a branch release-1.22. Could you confirm the tag, please?
> > >
> > > -Bruno
> > >
> > > On Wed, 26 Oct 2022 at 09:05, Matt Sicker  wrote:
> > >
> > >> We have fixed quite a few bugs and added some significant enhancements
> > >> since Apache Commons Compress 1.21 was released, so I would like to
> > release
> > >> Apache Commons Compress 1.22.
> > >>
> > >> Apache Commons Compress 1.22 RC1 is available for review here:
> > >>https://dist.apache.org/repos/dist/dev/commons/compress/1.22-RC1
> > (svn
> > >> revision 57596)
> > >>
> > >> The Git tag commons-compress-1.22-RC1 commit for this RC is
> > >> 5183d0b08c0897e6f0c41a038487b7c795136425 which you can browse here:
> > >>
> > >>
> > https://gitbox.apache.org/repos/asf?p=commons-compress.git;a=commit;h=5183d0b08c0897e6f0c41a038487b7c795136425
> > >> You may checkout this tag using:
> > >>git clone https://gitbox.apache.org/repos/asf/commons-compress.git
> > >> --branch commons-compress-1.22-RC1 commons-compress-1.22-RC1
> > >>
> > >> Maven artifacts are here:
> > >>
> > >>
> > https://repository.apache.org/content/repositories/orgapachecommons-1603/org/apache/commons/commons-compress/1.22/
> > >>
> > >> These are the artifacts and their hashes:
> > >>
> > >> #Release SHA-512s
> > >> #Tue Oct 25 14:46:59 CDT 2022
> > >> Apache\ Commons\
> > >>
> > Compress-1.22.spdx.rdf.xml=aef6cc68bff93fe66c70ffb486a3f9e5709ada04e51c8eb5901368eb9e7ce627885b367123c3db86912b3625d374d0bf02610edb86fe223ae974bab2fa60bec2
> > >>
> > >>
> > commons-compress-1.22-bin.tar.gz=81f0f1e75797d7199e8eb399f26571955f27040b4255859ec4df73714a2edd0d7238823201ffd486bf18f1cbf80ff7f28dbd4f5ad4655826468775ceec224d55
> > >>
> > >>
> > commons-compress-1.22-bin.zip=ccfeaa45ba257d6895fd849a1d31f88498d4ada23502318dd94747f00e9662e6ca335ab458b12436024c4cb25cef723393e0336534c6fc978b27aaa4b0e82650
> > >>
> > >>
> > commons-compress-1.22-bom.json=24dcbf472caf173e1ed4151867451bd457b581c86e1cd24a045ddbe3e4a139916598dbf51b87d3f299f30d0029f62a65981e42e48dd74efb44fa1068cde0fdc0
> > >>
> > >>
> > commons-compress-1.22-bom.xml=8e19c58886ff57ff078c88e90d6b1dcb21b48dc43df1ab69e7727ff11a5374e16e6f2dfc32fc5ed37ba4a0ccc065b6a41bdb00a60fd9789fb6d7b82094bb28ec
> > >>
> > >>
> > commons-compress-1.22-javadoc.jar=f7d10749afd6574cb6189d5701d310d5a7aae029d6d6b8a879d8dda4d9435f815fb671437c876f0f74cf7d8ebd219b04a2c903cc83a2bd8ddf63225f69add06c
> > >>
> > >>
> > commons-compress-1.22-sources.jar=94c2a396e831cdfcee438958a58fe5ca70b53b4884cd665568805ad0519f8ca12e960e2ce92ea73d70e414c6dd4a5f8c562bc758e19f5bffb06b696fb5589b6d
> > >>
> > >>
> > commons-compress-1.22-src.tar.gz=7d9e34d9a23e81778574fce2e637b380ef5027f3fc262f2583ec9568cfd16b766ec591a025f78987e2290a4a193992f4621c3ca05104e8e17a9cc32efdde8487
> > >>
> > >>
> > commons-compress-1.22-src.zip=fa8fec592d255f5ef23ce27491db9523222ed90113e7efd02fd9cc126d5e2df3d9caa578d049df0cca1f299e54d416295002b7f9c24e87b4b77b5c54658013bb
> > >>
> > >>
> > 

  1   2   >