Re: [collections] BloomFilterExtractor.flatten()

[Alex Herbert]

You cannot return an empty BloomFilter when there is no array of
BloomFilters to flatten. The BloomFilter is tied to a Shape. Without a
shape you cannot know what size filter to create. So we have to return
null or throw an exception. Whatever choice must be documented.

Note we do not currently check if the Shapes are all equal when
creating the BloomFilterExtractor. This is not essential but when
merging two Bloom filters in flatten an error will be thrown if the
filters are not compatible. I say it is not essential as the
functionality of the BloomFilterExtract in processBloomFilters does
not mandate any prerequisites on the Predicate for the filters. So for
example you could have many filters of different sizes and a predicate
that tests if they all contain a given IndexProducer.

Alex

On Fri, 4 Oct 2024 at 18:02, Gary Gregory  wrote:
>
> OK, but how do you create an empty filter?
>
> Gary
>
> On Fri, Oct 4, 2024, 12:54 PM Claude Warren  wrote:
>
> > I think that it should return an empty filter as the javadoc says
> >
> >
> > On Fri 4 Oct 2024, 15:53 Gary D. Gregory,  wrote:
> >
> > > See the new disabled test BloomFilterExtractorTest.
> > >
> > > Gary
> > >
> > > On 2024/10/04 14:51:55 "Gary D. Gregory" wrote:
> > > > Hi Claude and all,
> > > >
> > > > The method:
> > > >
> > > >
> > >
> > org.apache.commons.collections4.bloomfilter.BloomFilterExtractor.flatten()
> > > >
> > > > is documented as always returning a BloomFilter:
> > > >
> > > > /**
> > > >  * Create a standard (non-layered) Bloom filter by merging all of
> > > the layers. If
> > > >  * the filter is empty this method will return an empty Bloom
> > filter.
> > > >  *
> > > >  * @return the merged bloom filter.
> > > >  */
> > > >
> > > > But that's not how it's coded, it can return null, the simplest
> > > reproducer is:
> > > >
> > > > BloomFilterExtractor.fromBloomFilterArray(new BloomFilter[0]).flatten()
> > > -> null
> > > >
> > > > Should we:
> > > >
> > > > - Change the Javadoc
> > > > - Change the code
> > > > -- How should this code be changed?
> > > > -- Should the method be moved to BloomFilter and use "this" as the
> > > default filter?
> > > >
> > > > 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
> > >
> > >
> >

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

Re: [collection] AbstractLinkedListForJava21 ?

[Alex Herbert]

It was copied from the same package. The current AbstractLinkedList is
source incompatible with JDK 21 due to new default methods added to
the List interface. So Collections does not compile on JDK 21. Anyone
using the AbstractLinkedList and compiling on JDK 21 must switch their
source to use AbstractLinkedListForJava21.

If this is not clear from the javadoc and linked issue in the commit
log then we should do a better job explaining this.

Alex

On Wed, 11 Sept 2024 at 21:52, Gary D. Gregory  wrote:
>
> Hi All:
>
> Added in 4.5.0-M2, I see a new class called AbstractLinkedListForJava21 with 
> the Javadoc: "This is a copy of AbstractLinkedList"
>
> Copied from where?
> What was the license of the source?
>
> If we cannot validate that this is copied from a source file with a 
> compatible license, we will have to remove it.
>
> 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

[ANNOUNCE] Apache Commons Statistics Version 1.1 Released

[Alex Herbert]

The Apache Commons Team is pleased to announce the availability of
version 1.1 of "Apache Commons Statistics".

Apache Commons Statistics provides tools for statistics.

Changes in this version include new descriptive, inference, ranking
and bom modules:

New features:
o STATISTICS-88:   "LogUniformDistribution": Add a log uniform distribution.
o STATISTICS-87:   "FoldedNormalDistribution": Add a folded normal
distribution implementation with
   specialized support for a half-normal distribution.
o STATISTICS-85:   Add a quantile and median implementation.
o STATISTICS-81:   Add descriptive statistics for integer types. These
allow improved accuracy and
   performance for int and long data using an array or
streams over using the
   equivalent double implementation via primitive conversion.
o STATISTICS-71:   Add commons-statistics-descriptive module for
implementations of univariate
   statistics. Contains base interfaces for statistics
and implementations for
   individual statistics (e.g. Min, Max, Sum, Mean,
Variance) and combinations of
   statistics. Thanks to Anirudh Joshi, Alex Herbert.
o STATISTICS-69:   "UncoditionedExactTest": Add an unconditioned exact
test for 2x2 contingency
   tables.
o STATISTICS-70:   "HypergeometricDistribution": Improve the summation
used for the cumulative
   probability functions.
o STATISTICS-66:   Add a Bill of Materials (BOM) to aid in dependency
management when referencing
   multiple Apache Commons Statistics artifacts. The
BOM should be used to ensure
   all imported artifacts are compatible.
o STATISTICS-64:   "FisherExactTest": Add Fisher's exact test for 2x2
contingency tables.
o STATISTICS-62:   Add a commons-statistics-inference module for
hypothesis testing. This ports and
   updates functionality in
org.apache.commons.math4.stat.inference including new
   support for one-sided hypothesis testing.
o STATISTICS-63:   Add a commons-statistics-ranking module for rank
transformations. This ports and
   updates functionality in
org.apache.commons.math4.stat.ranking.

Historical list of changes:
  https://commons.apache.org/proper/commons-statistics/changes-report.html

For complete information on Apache Commons Statistics, including
instructions on how
to submit bug reports, patches, or suggestions for improvement, see the
Apache Commons Statistics website:
  https://commons.apache.org/proper/commons-statistics/

Distribution packages can be downloaded from
  http://commons.apache.org/proper/commons-statistics/download_statistics.cgi

When downloading, please verify signatures using the KEYS file
available at
  https://downloads.apache.org/commons/KEYS

The Apache Commons Team

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

Re: [VOTE] Release Apache Commons Statistics 1.1 based on RC1

[Alex Herbert]

This vote passes with the following result:

+1: Bruno Kinoshita (binding)
+1: Gary Gregory (binding)
+1: Alex Herbert (binding)

Thanks to everyone who reviewed the candidate. I will proceed with the release.

Alex

On Tue, 20 Aug 2024 at 10:12, Alex Herbert  wrote:
>
> My +1
>
> On Mon, 19 Aug 2024 at 12:59, Gary Gregory  wrote:
> >
> > On Mon, Aug 19, 2024 at 7:21 AM Alex Herbert 
> > wrote:
> >
> > > On Sat, 17 Aug 2024 at 17:24, Gary Gregory  wrote:
> > > >
> > > > Thank you for the details Alex.
> > > >
> > > > WRT SBOM generation, I think this will be become more important as
> > > > time goes on, so anything we can do to improve the ecosystem will 
> > > > benefit
> > > > us all IMO.
> > >
> > > FYI: I traced the warning output in the SPDX plugin to an incorrect
> > > use of a regex. Ticket is here:
> > >
> > > https://github.com/spdx/Spdx-Java-Library/issues/247
> > >
> > > Hopefully this will be fixed in a subsequent release of the backing
> > > library.
> > >
> >
> > Great new that we have a ticket to track. Thank you for the debugging and
> > link.
> >
> > 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 Statistics 1.1 based on RC1

[Alex Herbert]

My +1

On Mon, 19 Aug 2024 at 12:59, Gary Gregory  wrote:
>
> On Mon, Aug 19, 2024 at 7:21 AM Alex Herbert 
> wrote:
>
> > On Sat, 17 Aug 2024 at 17:24, Gary Gregory  wrote:
> > >
> > > Thank you for the details Alex.
> > >
> > > WRT SBOM generation, I think this will be become more important as
> > > time goes on, so anything we can do to improve the ecosystem will benefit
> > > us all IMO.
> >
> > FYI: I traced the warning output in the SPDX plugin to an incorrect
> > use of a regex. Ticket is here:
> >
> > https://github.com/spdx/Spdx-Java-Library/issues/247
> >
> > Hopefully this will be fixed in a subsequent release of the backing
> > library.
> >
>
> Great new that we have a ticket to track. Thank you for the debugging and
> link.
>
> 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 Statistics 1.1 based on RC1

[Alex Herbert]

On Sat, 17 Aug 2024 at 17:24, Gary Gregory  wrote:
>
> Thank you for the details Alex.
>
> WRT SBOM generation, I think this will be become more important as
> time goes on, so anything we can do to improve the ecosystem will benefit
> us all IMO.

FYI: I traced the warning output in the SPDX plugin to an incorrect
use of a regex. Ticket is here:

https://github.com/spdx/Spdx-Java-Library/issues/247

Hopefully this will be fixed in a subsequent release of the backing library.

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

Re: [VOTE] Release Apache Commons Statistics 1.1 based on RC1

[Alex Herbert]

Thanks Gary, see notes below...

On Sat, 17 Aug 2024 at 15:12, Gary Gregory  wrote:
>
> +1
>
> - I tested the src zip files.
> - ASC OK
> - SHA512 OK
> - default Maven build OK
> - Odd output:
>
> [WARNING] 
> /Users/garydgregory/rc/stats/commons-statistics-1.1-src/commons-statistics-descriptive/src/main/java/org/apache/commons/statistics/descriptive/Statistics.java:[215,25]
> compose(java.util.function.LongConsumer...) in
> org.apache.commons.statistics.descriptive.Statistics is potentially
> ambiguous with compose(java.util.function.IntConsumer...) in
> org.apache.commons.statistics.descriptive.Statistics

This is strange. I can repeat this on JDK 8 (Terumin) and 11, 17, 21
on my Macbook (all Temurin). I don't recall seeing it before. As it is
just a warning I think this is OK. I will change the method name in
git master. It is a static method on a package private util class so
will not change binary compatibility.

>
> [INFO] Creating SPDX File
> /Users/garydgregory/rc/stats/commons-statistics-1.1-src/commons-statistics-distribution/target/site/org.apache.commons_commons-statistics-distribution-1.1.spdx.json
> [WARNING] The following errors were found in the SPDX file:
>  License list version does not match the pattern M.N

I always see this warning. I thought it was normal given I have not
configured anything overriding commons parent related to the SPDX
plugin. I do not know what exactly the SPDX plugin is expecting for
the license configuration.

Note that: 
target/site/org.apache.commons_commons-statistics-ranking-1.1-SNAPSHOT.spdx.json
contains:

"licenseConcluded" : "Apache-2.0",
"licenseDeclared" : "Apache-2.0",
"licenseInfoFromFiles" : [ "NOASSERTION" ],

So it does write in some details about the license.

Looking at for example commons lang or text, this also has the same
warning. I will have to investigate this further, probably by digging
into the source code for the SPDX plugin.

>
> INFO] --- javadoc:3.8.0:javadoc (default-cli) @ commons-statistics-docs ---
> [ERROR] Error fetching link:
> /Users/garydgregory/rc/stats/commons-statistics-1.1-src/commons-statistics-distribution/target/apidocs.
> Ignored it.
> [ERROR] Error fetching link:
> /Users/garydgregory/rc/stats/commons-statistics-1.1-src/commons-statistics-descriptive/target/apidocs.
> Ignored it.
> [ERROR] Error fetching link:
> /Users/garydgregory/rc/stats/commons-statistics-1.1-src/commons-statistics-ranking/target/apidocs.
> Ignored it.
> [ERROR] Error fetching link:
> /Users/garydgregory/rc/stats/commons-statistics-1.1-src/commons-statistics-inference/target/apidocs.
> Ignored it.
> [INFO] No previous run data found, generating javadoc.

This always happens. But the docs module does build javadoc for the
entire set of modules so it achieves its purpose for the site build.

I will take a look as it may require some particular maven build
targets to be run in the dependency projects for javadoc.

Note that only the inference module depends on other modules (ranking;
distribution). However I believe there is nothing in the public API
from the other modules. So it cannot be known if this warning leads to
an incorrectly cross referenced javadoc.

Alex

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

[VOTE] Release Apache Commons Statistics 1.1 based on RC1

[Alex Herbert]

We have fixed a few bugs and added enhancements since Apache Commons
Statistics 1.0 was released, so I would like to release Apache Commons
Statistics 1.1.

Apache Commons Statistics 1.1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/statistics/1.1-RC1
(svn revision 70945)

The Git tag commons-statistics-1.1-RC1 commit for this RC is
commons-statistics-1.1-RC1 which you can browse here:

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

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1773/org/apache/commons/commons-statistics/1.1/

These are the artifacts and their hashes:

#Release SHA-512s
#Fri Aug 16 14:53:41 BST 2024
commons-statistics-1.1-bin.tar.gz=fb447bc420f3262b32e8720ce6880cbc29b6dc30f9d55d4196d8d1d51fc7b65633500ab55178a45f14c130ccebde08ebb3639face3b33ac8387392cef0f245ec
commons-statistics-1.1-bin.zip=928b59c88b56f9ad05b7d4cb4d5686b15544fcbee5630fcfa351826d99331c9178c7dad7ce98edec9f265b003d688f3f4ffcc59f4f33a5681a5e0b92d567dee3
commons-statistics-1.1-src.tar.gz=f774c6c2e4263da0674c4b6686ce364d91150d35a838013093d3a3a7749487b9e2672c09f387aac03884cfab42ac9d0f447abafbdd54dd8bc52dd2613c79b8c7
commons-statistics-1.1-src.zip=7a97210d5e3e8ef9bb2628d76dc04530d312f6322c83d9bf35e1bdcda04571e1c691d6d67004ee4b1b0a8d1ac3ccb8c323f3884b6728718a225af27a137229d1


I have tested this with 'mvn clean install' and 'mvn clean package
site site:stage -Pexamples' 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.6.1", arch: "aarch64", family: "mac"

Details of changes since 1.0 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/statistics/1.1-RC1/RELEASE-NOTES.txt

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

Site:

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

*** Note that the site layout rendering for sub-modules is not fully
supported in the dist staging area (reasons unknown). ***

JApiCmp Report (compared to 1.0):

https://dist.apache.org/repos/dist/dev/commons/statistics/1.1-RC1/site/commons-statistics-distribution/japicmp.html

Note: Release 1.0 only contained the distribution module. New
modules for 1.1 are descriptive, inference and ranking.

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/statistics/1.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...

Thank you,

Alex Herbert,
Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)

The 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-statistics.git
--branch commons-statistics-1.1-RC1 commons-statistics-1.1-RC1
cd commons-statistics-1.1-RC1

1b) Download and unpack the source archive from:

https://dist.apache.org/repos/dist/dev/commons/statistics/1.1-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

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 gather OS information from a command line:
Windows: ver
Linux: uname -a

5) Build the site for a multi-module project

mvn site
mvn site:stage
Check the site reports in:
- Windows: target\site\index.html
- Linux: target/site/index.html

Note that the project reports are created for each module.
Modules can be accessed using the 'Project Modules' li

[release] No description on staged Nexus repo

[Alex Herbert]

To release managers,

During the staging of Statistics 1.1 RC1 I made an error and did not
add a description when closing Nexus repo 1773. The repository
contents are OK. Please do not drop this repo during housekeeping.

Alex

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

[ANNOUNCE] Apache Commons Numbers Version 1.2 Released

[Alex Herbert]

The Apache Commons Team is pleased to announce the availability of
version 1.2 of "Apache Commons Numbers".

Apache Commons Numbers provides number types and utilities.

Changes in this version include:

New features:
o NUMBERS-206:  "Selection": Add selection of the k-th ordered element
from an array.
o NUMBERS-205:  "Addition/Multiplication": Introduces isZero to
Addition and isOne to Multiplication
interfaces. Override the default implementation in
implementing classes to avoid
expensive equals(Object) operations. Thanks to Harald Kirsch.
o NUMBERS-203:  "DDField": Add a field for the DD number.
o NUMBERS-193:  "DD": Add an extended precision floating-point number.
A double-double (DD) number
is an unevaluated sum of two IEEE double precision numbers
capable of representing
at least 106 bits of significand.
o NUMBERS-192:  "Sum": Add subtract(Sum) method.
o NUMBERS-191:  "Stirling": Compute Stirling numbers of the first kind.
o NUMBERS-29:  Add "Stirling" class to compute Stirling numbers of the
second kind.

Fixed Bugs:
o NUMBERS-204:  "Sum": Correct sub-normal round-off computation in sum
of products.
o NUMBERS-201:  "FP64": Make equals consistent with hashCode.
o NUMBERS-200:  "Sum": Avoid a NaN result when combining Sum instances
with infinite sums
of the same sign. Thanks to Anirudh Joshi.

Changes:
o   "ArithmeticUtils": Improve performance of GCD for longs.
Thanks to Matthias Langer.
o   "ArithmeticUtils": Improve performance of
remainderUnsigned and divideUnsigned.
Thanks to Sebb, Alex Herbert.
o NUMBERS-199:  "Precision": Document inaccurate decimal value
representation when converting
to and from a double in the round method.

Historical list of changes:
  https://commons.apache.org/proper/commons-numbers/changes-report.html

For complete information on Apache Commons Numbers, including
instructions on how
to submit bug reports, patches, or suggestions for improvement, see the
Apache Commons Numbers website:
  https://commons.apache.org/proper/commons-numbers/

Distribution packages can be downloaded from
  http://commons.apache.org/proper/commons-numbers/download_numbers.cgi

When downloading, please verify signatures using the KEYS file
available at
  https://downloads.apache.org/commons/KEYS

The Apache Commons Team

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

Re: [VOTE][RESULT] Release Apache Commons Numbers 1.2 based on RC1

[Alex Herbert]

This vote passes with the following result:

+1: Bruno Kinoshita (binding)
+1: Gary Gregory (binding)
+1: Tomas Lanik
+1: Gilles Sadowski (binding)
+1: Alex Herbert (binding)

Thanks to everyone who voted.

Alex


On Mon, 12 Aug 2024 at 10:27, Alex Herbert  wrote:
>
> My +1.
>
> Alex
>
> On Sat, 10 Aug 2024 at 01:25, Gilles Sadowski  wrote:
> >
> > Hi.
> >
> > $ git clone https://gitbox.apache.org/repos/asf/commons-numbers.git
> > --branch commons-numbers-1.2-RC1 commons-numbers-1.2-RC1
> > $ cd commons-numbers-1.2-RC1
> > $ git tag -v commons-numbers-1.2-RC1
> > -> OK
> >
> > $ mvn clean package site site:stage -Pexamples
> > -> OK
> >
> > $ mvn -v
> > Apache Maven 3.6.3
> > Maven home: /usr/share/maven
> > Java version: 11.0.23, vendor: Debian, runtime:
> > /usr/lib/jvm/java-11-openjdk-amd64
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "linux", version: "5.10.0-23-amd64", arch: "amd64", family: "unix"
> >
> > > [...]
> > >
> > > These are the artifacts and their hashes:
> > >
> > > #Release SHA-512s
> > > #Thu Aug 08 15:30:08 BST 2024
> > > commons-numbers-1.2-bin.tar.gz=b97c0ca2df1796c1ff8932134edb16c5156198900ec23623ad6ff99080ce7f44603a8bc1ab488234ec9761f650a6f628aece582cfae31c97e9cec110f7fe298f
> > > commons-numbers-1.2-bin.zip=bab72867ab6ea80e68ea8d0880278cae210fbda48f1d92a83dc06481410662b0d90b51fa2411cf5faf4bcbab52e2d7578b13c968e344d060f9902d90ee1f2270
> > > commons-numbers-1.2-src.tar.gz=f1cd6e0b70497977549d881a26aeb96cb4ff2cd3500290498d279ee6425b82ca681216353b5461df33df46d4fef7e766f983fa41a739dbd4bd77da71b42509be
> > > commons-numbers-1.2-src.zip=f0faee4a26ed692a15f02cca2d5a2224047cb7c404dcef35f832346cf101ebdb4f25e9efec2333a70c1718b6750942c1db6bb5d71082a1288a8ce38a2f357562
> >
> > I still don't get why the (generated ?) message puts the hashes in the above
> > format while the "sha512sum" command-line tool would need the following:
> > $ cat hash.txt
> > b97c0ca2df1796c1ff8932134edb16c5156198900ec23623ad6ff99080ce7f44603a8bc1ab488234ec9761f650a6f628aece582cfae31c97e9cec110f7fe298f
> > binaries/commons-numbers-1.2-bin.tar.gz
> > bab72867ab6ea80e68ea8d0880278cae210fbda48f1d92a83dc06481410662b0d90b51fa2411cf5faf4bcbab52e2d7578b13c968e344d060f9902d90ee1f2270
> > binaries/commons-numbers-1.2-bin.zip
> > f1cd6e0b70497977549d881a26aeb96cb4ff2cd3500290498d279ee6425b82ca681216353b5461df33df46d4fef7e766f983fa41a739dbd4bd77da71b42509be
> > source/commons-numbers-1.2-src.tar.gz
> > f0faee4a26ed692a15f02cca2d5a2224047cb7c404dcef35f832346cf101ebdb4f25e9efec2333a70c1718b6750942c1db6bb5d71082a1288a8ce38a2f357562
> > source/commons-numbers-1.2-src.zip
> > $ sha512sum -c hash.txt
> > binaries/commons-numbers-1.2-bin.tar.gz: OK
> > binaries/commons-numbers-1.2-bin.zip: OK
> > source/commons-numbers-1.2-src.tar.gz: OK
> > source/commons-numbers-1.2-src.zip: OK
> >
> > Is the purpose of the "signature-validator.sh" script (present in the
> > "dist" directory) to also check the artefacts on the Nexus server?
> > [I don't know how to do that...]
> >
> > >
> > > I have tested this with 'mvn clean install' and
> > > 'mvn clean package site site:stage -Pexamples' 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.6", arch: "aarch64", family: "mac"
> > >
> > > Note: The examples require Java 9+.
> > >
> > > Details of changes since 1.1 are in the release notes:
> > > 
> > > https://dist.apache.org/repos/dist/dev/commons/numbers/1.2-RC1/RELEASE-NOTES.txt
> > > 
> > > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/changes-report.html
> > >
> > > Site (the multi-module site has been staged on an Apache user home site):
> > > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/
> > > (note some *relative* links are broken and the 1.2 directories are
> > > not yet created - these will be OK once the site is deployed.)
> > >
> > > JApiCmp Report:
> > > 
> > > https://home.apache.org/~aherbert/commons-numbers-1

Re: [VOTE] Release Apache Commons Numbers 1.2 based on RC1

[Alex Herbert]

My +1.

Alex

On Sat, 10 Aug 2024 at 01:25, Gilles Sadowski  wrote:
>
> Hi.
>
> $ git clone https://gitbox.apache.org/repos/asf/commons-numbers.git
> --branch commons-numbers-1.2-RC1 commons-numbers-1.2-RC1
> $ cd commons-numbers-1.2-RC1
> $ git tag -v commons-numbers-1.2-RC1
> -> OK
>
> $ mvn clean package site site:stage -Pexamples
> -> OK
>
> $ mvn -v
> Apache Maven 3.6.3
> Maven home: /usr/share/maven
> Java version: 11.0.23, vendor: Debian, runtime:
> /usr/lib/jvm/java-11-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.10.0-23-amd64", arch: "amd64", family: "unix"
>
> > [...]
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Thu Aug 08 15:30:08 BST 2024
> > commons-numbers-1.2-bin.tar.gz=b97c0ca2df1796c1ff8932134edb16c5156198900ec23623ad6ff99080ce7f44603a8bc1ab488234ec9761f650a6f628aece582cfae31c97e9cec110f7fe298f
> > commons-numbers-1.2-bin.zip=bab72867ab6ea80e68ea8d0880278cae210fbda48f1d92a83dc06481410662b0d90b51fa2411cf5faf4bcbab52e2d7578b13c968e344d060f9902d90ee1f2270
> > commons-numbers-1.2-src.tar.gz=f1cd6e0b70497977549d881a26aeb96cb4ff2cd3500290498d279ee6425b82ca681216353b5461df33df46d4fef7e766f983fa41a739dbd4bd77da71b42509be
> > commons-numbers-1.2-src.zip=f0faee4a26ed692a15f02cca2d5a2224047cb7c404dcef35f832346cf101ebdb4f25e9efec2333a70c1718b6750942c1db6bb5d71082a1288a8ce38a2f357562
>
> I still don't get why the (generated ?) message puts the hashes in the above
> format while the "sha512sum" command-line tool would need the following:
> $ cat hash.txt
> b97c0ca2df1796c1ff8932134edb16c5156198900ec23623ad6ff99080ce7f44603a8bc1ab488234ec9761f650a6f628aece582cfae31c97e9cec110f7fe298f
> binaries/commons-numbers-1.2-bin.tar.gz
> bab72867ab6ea80e68ea8d0880278cae210fbda48f1d92a83dc06481410662b0d90b51fa2411cf5faf4bcbab52e2d7578b13c968e344d060f9902d90ee1f2270
> binaries/commons-numbers-1.2-bin.zip
> f1cd6e0b70497977549d881a26aeb96cb4ff2cd3500290498d279ee6425b82ca681216353b5461df33df46d4fef7e766f983fa41a739dbd4bd77da71b42509be
> source/commons-numbers-1.2-src.tar.gz
> f0faee4a26ed692a15f02cca2d5a2224047cb7c404dcef35f832346cf101ebdb4f25e9efec2333a70c1718b6750942c1db6bb5d71082a1288a8ce38a2f357562
> source/commons-numbers-1.2-src.zip
> $ sha512sum -c hash.txt
> binaries/commons-numbers-1.2-bin.tar.gz: OK
> binaries/commons-numbers-1.2-bin.zip: OK
> source/commons-numbers-1.2-src.tar.gz: OK
> source/commons-numbers-1.2-src.zip: OK
>
> Is the purpose of the "signature-validator.sh" script (present in the
> "dist" directory) to also check the artefacts on the Nexus server?
> [I don't know how to do that...]
>
> >
> > I have tested this with 'mvn clean install' and
> > 'mvn clean package site site:stage -Pexamples' 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.6", arch: "aarch64", family: "mac"
> >
> > Note: The examples require Java 9+.
> >
> > Details of changes since 1.1 are in the release notes:
> > 
> > https://dist.apache.org/repos/dist/dev/commons/numbers/1.2-RC1/RELEASE-NOTES.txt
> > 
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/changes-report.html
> >
> > Site (the multi-module site has been staged on an Apache user home site):
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/
> > (note some *relative* links are broken and the 1.2 directories are
> > not yet created - these will be OK once the site is deployed.)
> >
> > JApiCmp Report:
> > 
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-angle/japicmp.html
> > 
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-arrays/japicmp.html
> > 
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-combinatorics/japicmp.html
> > 
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-complex/japicmp.html
> > 
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-core/japicmp.html
> > 
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-field/japicmp.html
> > 
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-fraction/japicmp.html
> > 
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-gamma/japicmp.html
> > 
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-primes/japicmp.html
> > 
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-quaternion/japicmp.html
> > 
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-rootfinder/japicmp.html
>
> [I did not 

Re: [VOTE] Release Apache Commons Numbers 1.2 based on RC1

[Alex Herbert]

Thanks Bruno.

The site I put up is not from a clean build so these files are generated by
the release and then reported on by a second build for the site. I will add
exclusions for them to checkstyle.

Alex

On Thu, 8 Aug 2024, 21:14 Bruno Kinoshita,  wrote:

> +1
>
> Build from tag passing fine.
>
> Apache Maven 3.8.7
> Maven home: /usr/share/maven
> Java version: 17.0.12, vendor: Ubuntu, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "6.8.0-39-generic", arch: "amd64", family:
> "unix"
>
> Site reports look OK, but I think the checkstyle settings need some
> tweaking as they are complaining about missing headers in some build
> generated files, I think:
>
> https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/checkstyle.html
> .
> Not a big issue.
>
> Inspected signatures and contents of two files from dist area, and found no
> issues.
>
> Thanks!
>
> On Thu, 8 Aug 2024 at 17:03, Alex Herbert  wrote:
>
> > We have fixed a few bugs and added enhancements since Apache Commons
> > Numbers 1.1 was released, so I would like to release Apache Commons
> > Numbers 1.2.
> >
> > Apache Commons Numbers 1.2 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/numbers/1.2-RC1
> > (svn revision 70751)
> >
> > The Git tag commons-numbers-1.2-RC1 commit for this RC is
> > commons-numbers-1.2-RC1 which you can browse here:
> >
> >
> https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=commit;h=commons-numbers-1.2-RC1
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-numbers.git
> > --branch <
> https://gitbox.apache.org/repos/asf/commons-numbers.git--branch>
> > commons-numbers-1.2-RC1 commons-numbers-1.2-RC1
> >
> > Maven artifacts are here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1767/org/apache/commons/commons-numbers/1.2/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Thu Aug 08 15:30:08 BST 2024
> >
> >
> commons-numbers-1.2-bin.tar.gz=b97c0ca2df1796c1ff8932134edb16c5156198900ec23623ad6ff99080ce7f44603a8bc1ab488234ec9761f650a6f628aece582cfae31c97e9cec110f7fe298f
> >
> >
> commons-numbers-1.2-bin.zip=bab72867ab6ea80e68ea8d0880278cae210fbda48f1d92a83dc06481410662b0d90b51fa2411cf5faf4bcbab52e2d7578b13c968e344d060f9902d90ee1f2270
> >
> >
> commons-numbers-1.2-src.tar.gz=f1cd6e0b70497977549d881a26aeb96cb4ff2cd3500290498d279ee6425b82ca681216353b5461df33df46d4fef7e766f983fa41a739dbd4bd77da71b42509be
> >
> >
> commons-numbers-1.2-src.zip=f0faee4a26ed692a15f02cca2d5a2224047cb7c404dcef35f832346cf101ebdb4f25e9efec2333a70c1718b6750942c1db6bb5d71082a1288a8ce38a2f357562
> >
> > I have tested this with 'mvn clean install' and
> > 'mvn clean package site site:stage -Pexamples' 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.6", arch: "aarch64", family: "mac"
> >
> > Note: The examples require Java 9+.
> >
> > Details of changes since 1.1 are in the release notes:
> >
> >
> https://dist.apache.org/repos/dist/dev/commons/numbers/1.2-RC1/RELEASE-NOTES.txt
> >
> >
> https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/changes-report.html
> >
> > Site (the multi-module site has been staged on an Apache user home site):
> > https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/
> > (note some *relative* links are broken and the 1.2 directories are
> > not yet created - these will be OK once the site is deployed.)
> >
> > JApiCmp Report:
> >
> >
> https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-angle/japicmp.html
> >
> >
> https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-arrays/japicmp.html
> >
> >
> https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-combinatorics/japicmp.html
> >
> >
> https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-complex/japicmp.html
> >
> >
> https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-si

[VOTE] Release Apache Commons Numbers 1.2 based on RC1

[Alex Herbert]

We have fixed a few bugs and added enhancements since Apache Commons
Numbers 1.1 was released, so I would like to release Apache Commons
Numbers 1.2.

Apache Commons Numbers 1.2 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/numbers/1.2-RC1
(svn revision 70751)

The Git tag commons-numbers-1.2-RC1 commit for this RC is
commons-numbers-1.2-RC1 which you can browse here:

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

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1767/org/apache/commons/commons-numbers/1.2/

These are the artifacts and their hashes:

#Release SHA-512s
#Thu Aug 08 15:30:08 BST 2024
commons-numbers-1.2-bin.tar.gz=b97c0ca2df1796c1ff8932134edb16c5156198900ec23623ad6ff99080ce7f44603a8bc1ab488234ec9761f650a6f628aece582cfae31c97e9cec110f7fe298f
commons-numbers-1.2-bin.zip=bab72867ab6ea80e68ea8d0880278cae210fbda48f1d92a83dc06481410662b0d90b51fa2411cf5faf4bcbab52e2d7578b13c968e344d060f9902d90ee1f2270
commons-numbers-1.2-src.tar.gz=f1cd6e0b70497977549d881a26aeb96cb4ff2cd3500290498d279ee6425b82ca681216353b5461df33df46d4fef7e766f983fa41a739dbd4bd77da71b42509be
commons-numbers-1.2-src.zip=f0faee4a26ed692a15f02cca2d5a2224047cb7c404dcef35f832346cf101ebdb4f25e9efec2333a70c1718b6750942c1db6bb5d71082a1288a8ce38a2f357562

I have tested this with 'mvn clean install' and
'mvn clean package site site:stage -Pexamples' 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.6", arch: "aarch64", family: "mac"

Note: The examples require Java 9+.

Details of changes since 1.1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/numbers/1.2-RC1/RELEASE-NOTES.txt

https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/changes-report.html

Site (the multi-module site has been staged on an Apache user home site):
https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/
(note some *relative* links are broken and the 1.2 directories are
not yet created - these will be OK once the site is deployed.)

JApiCmp Report:

https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-angle/japicmp.html

https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-arrays/japicmp.html

https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-combinatorics/japicmp.html

https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-complex/japicmp.html

https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-core/japicmp.html

https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-field/japicmp.html

https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-fraction/japicmp.html

https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-gamma/japicmp.html

https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-primes/japicmp.html

https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-quaternion/japicmp.html

https://home.apache.org/~aherbert/commons-numbers-1.2-RC1-site/commons-numbers-rootfinder/japicmp.html

RAT Report:

https://home.apache.org/~aherbert/commons-numbers-1.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,

Alex Herbert,
Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)

The 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-numbers.git
--branch commons-numbers-1.2-RC1 commons-numbers-1.2-RC1
cd commons-numbers-1.2-RC1

1b) Download and unpack the source archive from:

https://dist.apache.org/repos/dist/dev/commons/numbers/1.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 compat

Re: [numbers][release] Nexus staging error for numbers 1.2 RC1

[Alex Herbert]

A reroll has fixed the nexus staging issue.

On Thu, 8 Aug 2024 at 15:24, Alex Herbert  wrote:
>
> I have just staged a release candidate for Commons Numbers 1.2 RC1.
> However nexus has created two repository IDs:
> 1765: contains all the expected module jars and signatures
> 1766: contains the only the parent pom
>
> In a strange twist all the metadata for the parent pom is in 1765, e.g.
> commons-numbers-parent-1.2.pom.asc
> commons-numbers-parent-1.2.pom.md5
>
> Staging did take a long time for the initial (parent) module. I am
> assuming a timeout error created a second staging repo. I will drop
> both nexus repositories and reroll.
>
> Alex

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

[numbers][release] Nexus staging error for numbers 1.2 RC1

[Alex Herbert]

I have just staged a release candidate for Commons Numbers 1.2 RC1.
However nexus has created two repository IDs:
1765: contains all the expected module jars and signatures
1766: contains the only the parent pom

In a strange twist all the metadata for the parent pom is in 1765, e.g.
commons-numbers-parent-1.2.pom.asc
commons-numbers-parent-1.2.pom.md5

Staging did take a long time for the initial (parent) module. I am
assuming a timeout error created a second staging repo. I will drop
both nexus repositories and reroll.

Alex

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

[ANNOUNCE] Apache Commons RNG 1.6 released

[Alex Herbert]

The Apache Commons Team is pleased to announce the availability of
version 1.6 of "Apache Commons RNG".

Apache Commons RNG provides Java implementations of pseudo-random
numbers generators.

Changes in this version include:

New features:
o RNG-186:  Correct the module OSGi exports. Use of multiple modules is
  validated in an OSGi integration test.
o RNG-184:  New "ArraySampler" to support shuffling primitive and generic
arrays
  with sub-range support.

Changes:
o RNG-183:  "InverseTransformParetoSampler": Modified to concentrate
samples at
  the distribution lower/upper bounds for extreme shape parameters.
Eliminates
  generation of outlier infinite samples and NaN samples under certain
  conditions. Changes sampling to use the RNG nextLong() method in-place of
  nextDouble().

Historical list of changes:
  https://commons.apache.org/proper/commons-rng/changes-report.html

For complete information on Apache Commons RNG, including instructions on
how
to submit bug reports, patches, or suggestions for improvement, see the
Apache Commons RNG website:
  https://commons.apache.org/proper/commons-rng/

Distribution packages can be downloaded from
  https://commons.apache.org/proper/commons-rng/download_rng.cgi

When downloading, please verify signatures using the KEYS file
available at
  https://downloads.apache.org/commons/KEYS

Maven artifacts are also available in the central Maven repository:
  https://repo.maven.apache.org/maven2/org/apache/commons/


  org.apache.commons
  commons-rng-client-api
  1.6

  org.apache.commons
  commons-rng-simple
  1.6

  org.apache.commons
  commons-rng-sampling
  1.6


The Apache Commons Team

Re: [VOTE] Release Apache Commons Codec 1.17.1 based on RC1

[Alex Herbert]

Built from the source archive commons-codec-1.17.1-src.tar.gz using:

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /Users/ah403/software/apache-maven-3
Java version: 21.0.3, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "14.5", arch: "aarch64", family: "mac"

Default goal:

mvn

Works OK. Lots of javadoc warnings about undocumented classes in the
codec/language packages.

Site build:

mvn -DskipTests package site -Pjapicmp

Works OK.

There is barely any coverage of the cli package. This could do with an
integration test to run the main function for the command-line program.

Q. Is this program even documented? It could be added to the user guide. It
does work as the following matches the VOTE SHA512 checksum:

java -cp target/commons-codec-1.17.1.jar
org.apache.commons.codec.cli.Digest SHA512
../commons-codec-1.17.1-src.tar.gz
c98456664396d4d9cb794c185a479e6bb4a5055ed1f526a8e358fe3a59409c057dbb16f59c251bb52976995dbca14d8f15857074c9d19fbc7bdfed625a13abf0
 ../commons-codec-1.17.1-src.tar.gz

Lots of warnings from PMD, CPD and SpotBugs. These have been around a
while. Perhaps a tidy up with some rule exclusions could be made for things
that will not be fixed before 2.0 (e.g. naming conventions).

+1: release these artifacts

Alex


On Mon, 15 Jul 2024 at 07:48, Tomas Lanik  wrote:

> My +1
>
> Tomas Lanik
>
> On Fri, Jul 12, 2024, 18:29 Gary Gregory  wrote:
>
> > We have added one enhancement and updated some dependencies since
> > Apache Commons Codec 1.17.0 was released, so I would like to release
> > Apache Commons Codec 1.17.1.
> >
> > Apache Commons Codec 1.17.1 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/codec/1.17.1-RC1
> > (svn revision 70271)
> >
> > The Git tag commons-codec-1.17.1-RC1 commit for this RC is
> > 965109705c5236b05011e1c45f47d991abfa521e which you can browse here:
> >
> >
> https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=965109705c5236b05011e1c45f47d991abfa521e
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-codec.git
> > --branch 
> > commons-codec-1.17.1-RC1 commons-codec-1.17.1-RC1
> >
> > Maven artifacts are here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1756/commons-codec/commons-codec/1.17.1/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Fri Jul 12 16:20:56 UTC 2024
> >
> >
> commons-codec-1.17.1-bin.tar.gz=6b7f60cc545b7524c8145ea2894983445db216feb06559809606c2fa274ab05cae72e9bd85fa1ae6f6f9997c13f940e18c5d6ac3019acfd77fcbb90f92402b5b
> >
> >
> commons-codec-1.17.1-bin.zip=2733187cbb65cea05bbd92b09f175c85440db594b5021505d71f580600e9e50a3aeb0d389f8c109ed3227c34ca395a34a764a4f4799fcc86d4ab174829b2aff5
> >
> >
> commons-codec-1.17.1-bom.json=8990802e9d665e8c151b0650268bbe767a1877349a8ab4b6fc271c19594c4304d6bab8250b13d8f1e67a4e01b49db83d10359c49d0597e3d8aceb0a69f697cd5
> >
> >
> commons-codec-1.17.1-bom.xml=0fd310815ceb760981120732a3e71d92fe5aff4f36e076a4341618019d2e6540bdfdb2bbb7e2c9e3865791156a26868707c3e3bd6bc576b6212f4264b341d36e
> >
> >
> commons-codec-1.17.1-javadoc.jar=67ed6f8748842fc81789e96ab6081344950b0986a36b512bfc3502ac696e5142fad6a29d5b27d581dd55e1892c7d99bb478ffa88d25dc0612b067c9a3a2796fc
> >
> >
> commons-codec-1.17.1-sources.jar=91853458bdc6d6cf9a1f344b30218ca28e9270341346a5431b714007456e8f08be700fd8fb7cc509afda69d996dde20e1f01022c59240428f5b41e3db2cf20c0
> >
> >
> commons-codec-1.17.1-src.tar.gz=c98456664396d4d9cb794c185a479e6bb4a5055ed1f526a8e358fe3a59409c057dbb16f59c251bb52976995dbca14d8f15857074c9d19fbc7bdfed625a13abf0
> >
> >
> commons-codec-1.17.1-src.zip=8375246b08c7c7c9f4f8d07f229c7b4dcc2eed8c1e9f2f7d59319a755c4b8f2b81e8ec5b0de995f239246f06e9b8ca373ae1563c385a5bb2a2377249b2662690
> >
> >
> commons-codec-1.17.1-test-sources.jar=d1fe18cffa43fec7e12f6d9e367872cad2539b1c6e9befd4dbbd7cc097137f780a0d86d0d15e6c921494f22a37077df94ee4c008fe395f76d9041cc8df86fed5
> >
> >
> commons-codec-1.17.1-tests.jar=52bfb28dad735490444a4f8ff96102013d23d9ecb22236aa0fb30d060113953105f65083eb831d34162b11bcc1de9c89a0a02b78e0582d04789182f8fd559aec
> >
> >
> commons-codec_commons-codec-1.17.1.spdx.json=402887cb1d559aa75efe3546c1d50e6a8e632339ff0fe66447878cbbd487df822232582d49c5b385e44cfd3adb0d6e06029ae561844f4d0eed1172441e853102
> >
> > I have tested this with 'mvn' and 'mvn -e -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.8 (36645f6c9b5079805ea5009217e36f2cffd34256)
> > Maven home: /usr/local/Cellar/maven/3.9.8/libexec
> > Java version: 17.0.11,

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

[Alex Herbert]

This vote passes with the following votes:

+1: Gilles Sadowski (binding)
+1: Gary Gregory (binding)
+1: Alex Herbert (binding)

Thanks to all who inspected RC1 and 2.

Alex


On Fri, 12 Jul 2024 at 14:51, Gary D. Gregory  wrote:

> +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&qu

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

[Alex Herbert]

RC1 is cancelled for RC2

On Tue, 9 Jul 2024 at 12:12, Gary Gregory  wrote:

> Thanks Alex!
>
> Gary
>
> On Mon, Jul 8, 2024, 4:22 PM Alex Herbert 
> wrote:
>
> > Hi Gary,
> >
> > Thanks for the feedback. I'll fix the docs module tomorrow. It is only
> for
> > an aggregate javadoc report for the site. It depends on all the other jar
> > modules and builds a single aggregate javadoc. This requires it to be a
> jar
> > artifact in the pom. But there is no output jar. I'll disable japicmp to
> > fix this. Really japicmp should handle a non-existent jar but it doesn't.
> >
> > The email I sent out is edited from the one built by the commons release
> > plugin. But I did not edit the site link (oops). The site is not staged
> > correctly for a multi-module jar. So I built the site separately and put
> it
> > in a personal Apache site. This makes it easy to see all the site
> including
> > the examples (which are not officially released but documented in the
> > site).
> >
> > Note: I cancelled this vote as some intentionally private constructors
> were
> > public.
> >
> > Alex
> >
> >
> > On Mon, 8 Jul 2024 at 18:52, Gary D. Gregory 
> wrote:
> >
> > > 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:
> > >

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

[Alex Herbert]

My +1

Another review would be appreciated.

On Thu, 11 Jul 2024 at 21:13, Alex Herbert  wrote:

> RC2 is still ok. Only nits with the site generation so far.
>
> On Thu, 11 Jul 2024, 19:31 Gary Gregory,  wrote:
>
>> Is RC2 still alive or are there changes coming due to this discussion?
>>
>> TY,
>> Gary
>>
>> On Thu, Jul 11, 2024, 2:05 PM Rob Tompkins  wrote:
>>
>> >
>> >
>> > > On Jul 11, 2024, at 1:57 PM, Alex Herbert 
>> > wrote:
>> > >
>> > > Hi Gilles,
>> > >
>> > > Thanks for the feedback. It seems that revapi is not a robust plugin,
>> but
>> > > japicmp also has issues without the packaged jars. I'll make a note in
>> > the
>> > > RNG release guide to suggest the command to build the site.
>> > >
>> > > On Thu, 11 Jul 2024 at 17:27, Gilles Sadowski > > <mailto:gillese...@gmail.com>> wrote:
>> > >
>> > >> Hello.
>> > >>
>> > >> Le mar. 9 juil. 2024 à 14:22, Alex Herbert > > <mailto:aherb...@apache.org>> a écrit :
>> > >>>
>> > >>> 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
>> > >>
>> > >> It would be worth reminding that a copy/paste of the above on the
>> > >> command-line will not work (although the script outputs both "ERROR"
>> > >> and "SUCCESSFUL VALIDATION" which is confusing/misleading).
>> > >>
>> > >> Couldn't the script be auto-generated (rather than just copied I
>> > presume)
>> 

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

[Alex Herbert]

RC2 is still ok. Only nits with the site generation so far.

On Thu, 11 Jul 2024, 19:31 Gary Gregory,  wrote:

> Is RC2 still alive or are there changes coming due to this discussion?
>
> TY,
> Gary
>
> On Thu, Jul 11, 2024, 2:05 PM Rob Tompkins  wrote:
>
> >
> >
> > > On Jul 11, 2024, at 1:57 PM, Alex Herbert 
> > wrote:
> > >
> > > Hi Gilles,
> > >
> > > Thanks for the feedback. It seems that revapi is not a robust plugin,
> but
> > > japicmp also has issues without the packaged jars. I'll make a note in
> > the
> > > RNG release guide to suggest the command to build the site.
> > >
> > > On Thu, 11 Jul 2024 at 17:27, Gilles Sadowski  > <mailto:gillese...@gmail.com>> wrote:
> > >
> > >> Hello.
> > >>
> > >> Le mar. 9 juil. 2024 à 14:22, Alex Herbert  > <mailto:aherb...@apache.org>> a écrit :
> > >>>
> > >>> 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
> > >>
> > >> It would be worth reminding that a copy/paste of the above on the
> > >> command-line will not work (although the script outputs both "ERROR"
> > >> and "SUCCESSFUL VALIDATION" which is confusing/misleading).
> > >>
> > >> Couldn't the script be auto-generated (rather than just copied I
> > presume)
> > >> to also contain the "for-loop" specific to each component?
> > >>
> > >
> > > Maybe. There is a lot that could be improved in the release plugin for
> > > multi-module releases. I added that line manually to the vote email. I
> > > added a lot of other things too. The loop worked when copy and pasted
> > from
> > > my source email. Maybe line wrapping has broken it.
> > >
> >
> > Agreed that the plugin doesn’t 

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

[Alex Herbert]

Hi Gilles,

Thanks for the feedback. It seems that revapi is not a robust plugin, but
japicmp also has issues without the packaged jars. I'll make a note in the
RNG release guide to suggest the command to build the site.

On Thu, 11 Jul 2024 at 17:27, Gilles Sadowski  wrote:

> Hello.
>
> Le mar. 9 juil. 2024 à 14:22, Alex Herbert  a écrit :
> >
> > 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
>
> It would be worth reminding that a copy/paste of the above on the
> command-line will not work (although the script outputs both "ERROR"
> and "SUCCESSFUL VALIDATION" which is confusing/misleading).
>
> Couldn't the script be auto-generated (rather than just copied I presume)
> to also contain the "for-loop" specific to each component?
>

Maybe. There is a lot that could be improved in the release plugin for
multi-module releases. I added that line manually to the vote email. I
added a lot of other things too. The loop worked when copy and pasted from
my source email. Maybe line wrapping has broken it.

If we are not going to suggest using the signature validator, then why do
we even bother generating it? It seems strange, which is why I made an
attempt to suggest using it.


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

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

[Alex Herbert]

Hi Gilles,

On Thu, 11 Jul 2024 at 13:30, Gilles Sadowski  wrote:

>
> [In the cloned directory.]
> Default maven goal succeeds.
>
> >
> > mvn site
>
> The above goal fails:
> ---CUT---
> [INFO]
> 
> [INFO] Reactor Summary for Apache Commons RNG 1.6:
> [INFO]
> [INFO] Apache Commons RNG . SUCCESS [
> 12.508 s]
> [INFO] Apache Commons RNG Client API .. SUCCESS [
> 10.496 s]
> [INFO] Apache Commons RNG Core  FAILURE [
> 35.818 s]
> [INFO] Apache Commons RNG Simple .. SKIPPED
> [INFO] Apache Commons RNG Sampling  SKIPPED
> [INFO] Apache Commons RNG (Bill of Materials) . SKIPPED
> [INFO] Apache Commons RNG Documentation ... SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  59.002 s
> [INFO] Finished at: 2024-07-11T14:24:58+02:00
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.12.1:site (default-site)
> on project commons-rng-core: Error generating
> revapi-maven-plugin:0.15.0:report report: Failed to generate report.
> Failed to analyze archives in api
> API[archives=[org.apache.commons:commons-rng-core:jar:1.6],
> supplementary=[org.apache.commons:commons-rng-client-api:jar:1.6]]:
> Failed to copy class path element:
> org.apache.commons:commons-rng-client-api:jar:1.6 to
>
> /tmp/revapi-java11800467850945715013/lib/1-edd7d0b3-5c80-36e0-841b-e47ce34fb194:
>
> /home/gilles/gilles/devel/java/apache/release_check/commons-rng-1.6-RC2/commons-rng-client-api/target/classes
> (Is a directory) -> [Help 1]
> ---CUT---
>
>
I see the same behaviour:

mvn -DskipTests  # OK
mvn -DskipTests site   # Fails on the core module
mvn -DskipTests package site  # OK

# Using install:
mvn clean
mvn -DskipTests install
mvn -DskipTests site   # Still fails on the core module (there is a jar
in target)
mvn clean
mvn -DskipTests site   # Fails on the client-api module
mvn -DskipTests -Drevapi.skip site   # Fails on japicmp on the
client-api module

# Ignore revapi but ensure the target folder has a jar file
mvn -DskipTests
mvn -DskipTests -Drevapi.skip site   # OK

The binary compatibility plugins try to compare the jar files. If you do
not use the package goal then the revapi plugin does not appear to work
with pre-existing jar files from a previous build after the first module.
However japicmp can use previously built jar files (it doesn't fail the
build).

If the target dir does not contain a jar file then japicmp also fails (i.e.
it does not use locally installed jar files from the m2 repo).

So here japicmp does require a local jar file, but revapi does not work
with a local jar file after the first module. So this is a bug in revapi
when creating the site after a previous run to create the package.

Alex

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

[Alex Herbert]

I noticed that the recent change to the revapi plugin to remove a
deprecated property resulted in an empty report for RC2.

I checked the source code for revapi and the new reportCriticality
property is not used; only the deprecated reportSeverity property.

I have reverted the configuration in git master and this now generates the
correct report, although the plugin emits a warning about using a
deprecated property. This will not change the build of the source artifacts
apart from the site report. I have staged the correct report to the full
example site here:

https://home.apache.org/~aherbert/commons-rng-1.6-RC2-site/commons-rng-sampling/revapi-report.html

Note that JApiCmp creates a more useful report with the new methods
described for the new class:

https://home.apache.org/~aherbert/commons-rng-1.6-RC2-site/commons-rng-sampling/japicmp.html

The project uses two binary compatibility checks as a previous release
change was flagged as binary incompatible by JApiCmp but was not by revapi.
This required some exclusions for JApiCmp. The build still retains
configuration for both plugins.

Alex



On Tue, 9 Jul 2024 at 13:21, 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 p

[VOTE] Release Apache Commons RNG 1.6 based on RC2

[Alex Herbert]

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

https://home.apache.org/~aherbert/commons-rng-1.6-RC2-site/commons-rng-sampling/japicmp.html

RAT Report:

https://home.apache.org/~aherbert/commons-rng-1.6-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,

Alex Herbert,
Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)

The 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-rng.git --branch
commons-rng-1.6-RC2 commons-rng-1.6-RC2
cd commons-rng-1.6-RC2

1b) Download and unpack the source archive from:

https://dist.apache.org/repos/dist/dev/commons/rng/1.6-RC2/source

2) Check Apache licenses

This step is not requir

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

[Alex Herbert]

Hi Rob,

This behaviour is documented in the release note.

The tests for randomness use a random seed. So they fail with a given
probability. We have a set number of reruns configured. A few failures get
logged as a flake. If they fail 3 times then the build will fail. With a
p-value of 0.001 this will be 1 in a billion. But there are thousands of
tests. The build fail rate is closer to 1 in 1000 but I haven't done the
analysis on it for a while.

Hope that helps.

Alex




On Mon, 8 Jul 2024, 21:30 Rob Tompkins,  wrote:

> I was running the build on java 21 and got this:
> Results:
> [INFO]
> [WARNING] Flakes:
> [WARNING]
> org.apache.commons.rng.core.ProvidersCommonParametricTest.testUniformNextBytesPartialBuffer(UniformRandomProvider)[8]
> [ERROR]   Run 1:
> ProvidersCommonParametricTest.testUniformNextBytesPartialBuffer:124
> org.apache.commons.rng.core.source32.Well44497b ==> expected:  but
> was: 
> [INFO]   Run 2: PASS
> [INFO]
> [WARNING]
> org.apache.commons.rng.core.ProvidersCommonParametricTest.testUniformNextFloat(UniformRandomProvider)[25]
> [ERROR]   Run 1:
> ProvidersCommonParametricTest.testUniformNextFloat:167->checkNextFloat:418->checkNextInRange:528
> org.apache.commons.rng.core.source32.XoShiRo128PlusPlus: Too many failures
> for n = 1234, sample size = 1000 (12 out of 500 tests failed, chi2 >
> 21.666=[25.107, 26.161, 22.291, 21.885, 23.420, 32.030, 23.780, 21.808,
> 22.042, 22.531, 28.331, 25.669])
> [INFO]   Run 2: PASS
> [INFO]
> [WARNING]
> org.apache.commons.rng.core.ProvidersCommonParametricTest.testUniformNextFloat(UniformRandomProvider)[30]
> [ERROR]   Run 1:
> ProvidersCommonParametricTest.testUniformNextFloat:167->checkNextFloat:418->checkNextInRange:528
> org.apache.commons.rng.core.source64.TwoCmres (Cmres: [0xedce446814d3b3d9L,
> 33, 330658535] + Cmres: [0xc5b3cf786c806df7L, 33, 331932042]): Too many
> failures for n = 1234, sample size = 1000 (14 out of 500 tests failed, chi2
> > 21.666=[22.259, 23.260, 22.523, 30.913, 23.325, 22.569, 32.086, 24.000,
> 22.940, 23.656, 39.190, 23.015, 23.873, 24.451])
> [INFO]   Run 2: PASS
> [INFO]
> [WARNING]
> org.apache.commons.rng.core.ProvidersCommonParametricTest.testUniformNextIntegerInRange(UniformRandomProvider)[25]
> [ERROR]   Run 1:
> ProvidersCommonParametricTest.testUniformNextIntegerInRange:142->checkNextIntegerInRange:389->checkNextInRange:528
> org.apache.commons.rng.core.source32.XoShiRo128PlusPlus: Too many failures
> for n = 32, sample size = 1000 (13 out of 500 tests failed, chi2 >
> 21.666=[23.824, 25.531, 22.309, 23.461, 23.315, 22.693, 21.968, 21.749,
> 30.803, 23.157, 26.877, 22.016, 21.896])
> [INFO]   Run 2: PASS
> [INFO]
> [WARNING]
> org.apache.commons.rng.core.ProvidersCommonParametricTest.testUniformNextIntegerInRange(UniformRandomProvider)[2]
> [ERROR]   Run 1:
> ProvidersCommonParametricTest.testUniformNextIntegerInRange:139->checkNextIntegerInRange:389->checkNextInRange:528
> org.apache.commons.rng.core.source32.MersenneTwister: Too many failures for
> n = 10, sample size = 1000 (13 out of 500 tests failed, chi2 >
> 21.666=[23.920, 21.720, 22.440, 24.280, 23.920, 27.320, 22.680, 22.160,
> 34.440, 27.020, 29.680, 22.260, 22.400])
> [INFO]   Run 2: PASS
> [INFO]
> [WARNING]
> org.apache.commons.rng.core.ProvidersCommonParametricTest.testUniformNextLongInRange(UniformRandomProvider)[14]
> [ERROR]   Run 1:
> ProvidersCommonParametricTest.testUniformNextLongInRange:155->checkNextLongInRange:404->checkNextInRange:528
> org.apache.commons.rng.core.source32.XoShiRo128Plus: Too many failures for
> n = 31, sample size = 1000 (12 out of 500 tests failed, chi2 >
> 21.666=[24.651, 24.155, 21.915, 21.778, 22.584, 21.667, 22.667, 24.093,
> 31.256, 25.519, 22.101, 21.750])
> [INFO]   Run 2: PASS
> [INFO]
> [WARNING]
> org.apache.commons.rng.core.ProvidersCommonParametricTest.testUniformNextLongInRange(UniformRandomProvider)[16]
> [ERROR]   Run 1:
> ProvidersCommonParametricTest.testUniformNextLongInRange:156->checkNextLongInRange:404->checkNextInRange:528
> org.apache.commons.rng.core.source32.PcgXshRr32: Too many failures for n =
> 32, sample size = 1000 (12 out of 500 tests failed, chi2 > 21.666=[24.699,
> 23.464, 25.043, 31.397, 31.739, 22.288, 24.637, 22.547, 22.483, 21.939,
> 22.795, 21.973])
> [INFO]   Run 2: PASS
> [INFO]
> [INFO]
> [WARNING] Tests run: 2058, Failures: 0, Errors: 0, Skipped: 6, Flakes: 7
>
> Any thoughts?
>
> > On Jul 8, 2024, at 4:21 PM, Alex Herbert 
> wrote:
> >
> > Hi Gary,
> >
> > Thanks for the feedback. I'll fix the docs module tomorrow. It is only
> for
> > an aggregate javadoc report for the site. It depends on all the other jar
> > modules a

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

[Alex Herbert]

Hi Gary,

Thanks for the feedback. I'll fix the docs module tomorrow. It is only for
an aggregate javadoc report for the site. It depends on all the other jar
modules and builds a single aggregate javadoc. This requires it to be a jar
artifact in the pom. But there is no output jar. I'll disable japicmp to
fix this. Really japicmp should handle a non-existent jar but it doesn't.

The email I sent out is edited from the one built by the commons release
plugin. But I did not edit the site link (oops). The site is not staged
correctly for a multi-module jar. So I built the site separately and put it
in a personal Apache site. This makes it easy to see all the site including
the examples (which are not officially released but documented in the site).

Note: I cancelled this vote as some intentionally private constructors were
public.

Alex


On Mon, 8 Jul 2024 at 18:52, Gary D. Gregory  wrote:

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

[VOTE] Release Apache Commons RNG 1.6 based on RC1

[Alex Herbert]

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

https://home.apache.org/~aherbert/commons-rng-1.6-RC1-site/commons-rng-core/revapi-report.html

https://home.apache.org/~aherbert/commons-rng-1.6-RC1-site/commons-rng-simple/revapi-report.html

https://home.apache.org/~aherbert/commons-rng-1.6-RC1-site/commons-rng-sampling/revapi-report.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/rng/1.6-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,

Alex Herbert,
Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)

The 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

Re: [parent] Possibe change to moditect configuration for internal packages

[Alex Herbert]

Sealed classes are for restricted inheritance. This is not applicable here.
In the RNG module a whole set of utility classes have been placed in an
'internal' package. Given that these should not be used directly I think
the module exports can omit this package. The moditect plugin provides
example configuration to do this for an internal package, which is what I
am suggesting here.

Alex


On Thu, 4 Jul 2024 at 14:25, Gary Gregory  wrote:

> Can this alternatively be solved with Java's sealed class feature? That
> would require Java 17 though...
>
> Gary
>
> On Thu, Jul 4, 2024, 9:18 AM Alex Herbert 
> wrote:
>
> > The RNG component has an internal package. So to not export this in the
> > module info I had to tweak the exports for moditect inherited from
> commons
> > parent with a profile:
> >
> > 
> >   java-9-up
> >   
> > [9,)
> >   
> >   
> > 
> >   
> > org.moditect
> > moditect-maven-plugin
> > ${commons.moditect-maven-plugin.version}
> > 
> >   
> > 
> >   
> > !${commons.module.name}*.internal*;
> > *;
> >   
> > 
> >   
> > 
> >   
> > 
> >   
> > 
> >
> > This could be integrated to commons parent. However it may affect binary
> > compatibility on Java 9+ for any that do and have been released with the
> > default export of all packages.
> >
> > Are there any other components that use internal packages?
> >
> > Alex
> >
>

[parent] Possibe change to moditect configuration for internal packages

[Alex Herbert]

The RNG component has an internal package. So to not export this in the
module info I had to tweak the exports for moditect inherited from commons
parent with a profile:


  java-9-up
  
[9,)
  
  

  
org.moditect
moditect-maven-plugin
${commons.moditect-maven-plugin.version}

  

  
!${commons.module.name}*.internal*;
*;
  

  

  

  


This could be integrated to commons parent. However it may affect binary
compatibility on Java 9+ for any that do and have been released with the
default export of all packages.

Are there any other components that use internal packages?

Alex

[rng][numbers][statistics] Release latest dev versions

[Alex Herbert]

I would like to release the statistics component as it has some useful new
modules. This requires:

rng-1.6
numbers-1.2
statistics-1.1

I believe RNG is ready to go out now. It only has one new class and a fix
for the Java 9 module exports. I do not think the other components have any
outstanding items to integrate but let me know if there is something else
to include.

Alex

Re: TEST fails for commons-compress:1.26

[Alex Herbert]

Hi,

There have been some patch releases since 1.26. Can you try with the latest
release (1.26.2):

https://commons.apache.org/compress/download_compress.cgi

If this still doesn't work can you provide the output of 'mvn -v' when run
from within the source root directory. This will provide your build
platform details so we can try and reproduce the issue.

Thanks,

Alex


On Wed, 26 Jun 2024 at 17:28, sumera sum  wrote:

> Hi Team,
> I am able to build commons-compress from source code, but while trying to
> run the tests it fails with the following error. Please assist me on how to
> fix this
>
> > [INFO] Results:
> > [INFO]
> > [ERROR] Failures:
> > [ERROR]   TarArchiveEntryTest.testLinuxFileInformationFromFile:199
> > expected: not equal but was: <0>
> > [ERROR]   TarArchiveEntryTest.testLinuxFileInformationFromPath:208
> > expected: not equal but was: <0>
> > [ERROR] Errors:
> > [ERROR]   ListerTest.testMain:47 ? MalformedInput Input length = 1
> > [ERROR]
> >
> GzipCompressorOutputStreamTest.testFileNameChinesePercentEncoded:71->testFileName:38
> > ? InvalidPath Malformed input or input contains unmappable characters:
> > ??.xml12263541264916463068??.xml
> > [INFO]
> > [ERROR] Tests run: 2746, Failures: 2, Errors: 2, Skipped: 27
> > [INFO]
> > [INFO]
> > 
> > [INFO] BUILD FAILURE
> > [INFO]
> > 
> > [INFO] Total time:  46.075 s
> > [INFO] Finished at: 2024-06-24T12:26:41Z
> > [INFO]
> > 
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-surefire-plugin:3.2.5:test (default-test)
> on
> > project commons-compress: There are test failures.
> >
>
> Source URL:
>
> https://github.com/apache/commons-compress/archive/refs/tags/rel/commons-compress-1.26.0.zip
> BUILD COMMAND: mvn clean install -DskipTests
> TEST COMMAND: mvn test
> JAVA Version: 17.0.8
> MAVEN Version: 3.9.4
>
> Regards,
> Sumera
>

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

[Alex Herbert]

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

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

[Alex Herbert]

Hi,

On Wed, 12 Jun 2024 at 17:23, Department 8  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?
>

Is this different from:

public static boolean isAnyNotBlank(final CharSequence... css) {
return !isAllBlank(css);
}

If the implementation is as above then you add an extra method that must be
invoked using more characters than:

!StringUtils.isAllBlank(...)

This doesn't seem helpful. If there is more logic to the method then it may
be worth considering.

There are also the other methods that could be similarly negated:

isAllEmpty
isAllLowerCase
isAllUpperCase

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.

Alex

Re: [COLLECTIONS/Bloomfilter] A question of streams

[Alex Herbert]

You need to test it with some realistic data for a benchmark.

In Commons Statistics we have a case where all elements of an array are
passed to a consumer. So you have either:

int[] a = ...
IntConsumer c = ...

Arrays.stream(a).forEach(c::accept)

vs

for (final int i : a) {
c.accept(i);
}

When the array is less than 10 in length then the stream is noticeably
slower. When it is longer then the difference becomes mute as the cost of a
Stream is more of a constant than a scaling factor. It also depends on the
speed of the consumer as to whether you will notice. But (single threaded)
the loop is never slower. The stream provides the advantage of intermediate
state operations on the stream contents, and parallelisation. If you are
not using these then the stream is extra overhead.

So the questions are: how large is your collection that you are streaming;
what is consuming the stream; and how critical is the runtime performance
for this process?

Alex


On Wed, 12 Jun 2024 at 07:37, Claude Warren  wrote:

> There is/was a discussion in Cassandra Dev recently about the overhead of
> Java Streaming vs simple loops/iteration.  The consensus there is that
> streams should not be used in the hot path.  Discussion then devolved into
> determining hot path or banning outright.
>
> My question is should we remove the stream calls from the non-test
> bloomfilter code on the assumption that Bloom filters are always on the hot
> path.
>
> Claude
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>

Re: [Collections] Implementation of EnhancedDoubleHasher

[Alex Herbert]

Tracking this with:

https://issues.apache.org/jira/browse/COLLECTIONS-855

On Sat, 18 May 2024 at 08:26, Alex Herbert  wrote:

> Thanks for highlighting this. I did not use the original paper and based
> the implementation on Wikipedia.
>
> I think the issue is that we use i in [0, k); we can correct this by using
> i in [1, k]. The order inside the loop would not change but we would have
> to decrement i to use in the assignment giving:
>
> x, y := a(δ) MOD m, b(δ) MOD m
> for i := 1 .. k
> f[i - 1] := x
> x := (x + y) MOD m
> y := (y + i) MOD m
>
> This would fix the issue but has the inelegant extra computation at the
> end of the loop that is unused on the final execution. Note that the
> current implementation has this inelegant extra computation as well. We can
> update to remove this by reducing the loop size by 1 and using the first
> index outside the loop.
>
> When applying this change to the current repo we see 4 failures in the
> EnhancedDoubleHasherTest. These are corrected by changing the array of
> expected indices.
>
> Regards,
>
> Alex
>
>
>
>
> On Sat, 18 May 2024 at 07:23, Juan Manuel Gimeno Illa 
> wrote:
>
>> The code in the implementation of the EnhancedDoubleHasher is based on the
>> wikipedia article https://en.wikipedia.org/wiki/Double_hashing.
>>
>> The code that appears in the article is:
>>
>> struct key; /// Opaque
>> /// Use other data types when needed. (Must be unsigned for guaranteed
>> wrapping.)
>> extern unsigned int h1(struct key const *), h2(struct key const *);
>>
>> /// Calculate k hash values from two underlying hash functions
>> /// h1() and h2() using enhanced double hashing.  On return,
>> /// hashes[i] = h1(x) + i*h2(x) + (i*i*i - i)/6.
>> /// Takes advantage of automatic wrapping (modular reduction)
>> /// of unsigned types in C.
>> void ext_dbl_hash(struct key const *x, unsigned int hashes[], unsigned
>> int n)
>> {
>> unsigned int a = h1(x), b = h2(x), i;
>>
>> for (i = 0; i < n; i++) {
>> hashes[i] = a;
>> a += b; // Add quadratic difference to get cubic
>> b += i; // Add linear difference to get quadratic
>> // i++ adds constant difference to get linear
>> }
>> }
>>
>> And it is based on code from the paper "Bloom Filters in Probabilistic
>> Verification" by Peter C.
>> Dillinger and Panagiotis Manolios (
>> https://www.khoury.northeastern.edu/~pete/pub/bloom-filters-verification.pdf
>> )
>>
>> But the code that appears on that paper is:
>>
>> x, y := a(δ) MOD m, b(δ) MOD m
>> f[0] := x
>> for i := 1 .. k-1
>> x := (x + y) MOD m
>> y := (y + i) MOD m
>> f[i] := x
>>
>> which does the assignments to x, y (a, b in the wikipedia article) in a
>> different order.
>>
>> The same algorithm appears the thesis "Adaptive Approximate State Storage"
>> (http://peterd.org/pcd-diss.pdf)
>>
>> algorithm " Enhanced DoubleHashing"
>>
>> input x : "the element being added or queried"
>> input m : "number of bits in bit vector"
>> input k : "number of indices to compute"
>> output g[0 .. k - 1] : "array of indices"
>> uses h1, h2 : "hash functions"
>>
>> begin
>> a := h1(x)
>> b := h2(x)
>> g[0] := a
>> for i := 1 .. k - 1
>> begin
>> a := (a + b) MOD m
>> b := (b + i) MOD m
>> g[i] := a
>> end
>> end
>>
>> It's easy to see that the computation the enhanced double hash computes
>>
>> hash[i] = h1(x) + i * h2(x) + (i^3 - i) / 6
>>
>> if we use a=h1(x) and b=h2(x), generates the sequence:
>>
>> a, a + b, a + 2 * b + 1, a + 3 * b + 4, a + 4 * b + 10, ...
>>
>> And both your implementation and the wikipedia article generates
>>
>> a, a + b, a + 2 * b, a + 3 * b + 1, a + 4 * b + 4, ...
>>
>> So the last term in the sum lags one step behind.
>>
>> The solution, I think, is as simple as swapping the assignments of index
>> and inc in your implementation.
>>
>> I suppose the impact of this is nil, but I'm not an expert for judging
>> that.
>>
>> Thanks,
>>
>> Juan Manuel Gimeno
>>
>

Re: [Collections] Implementation of EnhancedDoubleHasher

[Alex Herbert]

Thanks for highlighting this. I did not use the original paper and based
the implementation on Wikipedia.

I think the issue is that we use i in [0, k); we can correct this by using
i in [1, k]. The order inside the loop would not change but we would have
to decrement i to use in the assignment giving:

x, y := a(δ) MOD m, b(δ) MOD m
for i := 1 .. k
f[i - 1] := x
x := (x + y) MOD m
y := (y + i) MOD m

This would fix the issue but has the inelegant extra computation at the end
of the loop that is unused on the final execution. Note that the current
implementation has this inelegant extra computation as well. We can update
to remove this by reducing the loop size by 1 and using the first index
outside the loop.

When applying this change to the current repo we see 4 failures in the
EnhancedDoubleHasherTest. These are corrected by changing the array of
expected indices.

Regards,

Alex




On Sat, 18 May 2024 at 07:23, Juan Manuel Gimeno Illa 
wrote:

> The code in the implementation of the EnhancedDoubleHasher is based on the
> wikipedia article https://en.wikipedia.org/wiki/Double_hashing.
>
> The code that appears in the article is:
>
> struct key; /// Opaque
> /// Use other data types when needed. (Must be unsigned for guaranteed
> wrapping.)
> extern unsigned int h1(struct key const *), h2(struct key const *);
>
> /// Calculate k hash values from two underlying hash functions
> /// h1() and h2() using enhanced double hashing.  On return,
> /// hashes[i] = h1(x) + i*h2(x) + (i*i*i - i)/6.
> /// Takes advantage of automatic wrapping (modular reduction)
> /// of unsigned types in C.
> void ext_dbl_hash(struct key const *x, unsigned int hashes[], unsigned int
> n)
> {
> unsigned int a = h1(x), b = h2(x), i;
>
> for (i = 0; i < n; i++) {
> hashes[i] = a;
> a += b; // Add quadratic difference to get cubic
> b += i; // Add linear difference to get quadratic
> // i++ adds constant difference to get linear
> }
> }
>
> And it is based on code from the paper "Bloom Filters in Probabilistic
> Verification" by Peter C.
> Dillinger and Panagiotis Manolios (
> https://www.khoury.northeastern.edu/~pete/pub/bloom-filters-verification.pdf
> )
>
> But the code that appears on that paper is:
>
> x, y := a(δ) MOD m, b(δ) MOD m
> f[0] := x
> for i := 1 .. k-1
> x := (x + y) MOD m
> y := (y + i) MOD m
> f[i] := x
>
> which does the assignments to x, y (a, b in the wikipedia article) in a
> different order.
>
> The same algorithm appears the thesis "Adaptive Approximate State Storage"
> (http://peterd.org/pcd-diss.pdf)
>
> algorithm " Enhanced DoubleHashing"
>
> input x : "the element being added or queried"
> input m : "number of bits in bit vector"
> input k : "number of indices to compute"
> output g[0 .. k - 1] : "array of indices"
> uses h1, h2 : "hash functions"
>
> begin
> a := h1(x)
> b := h2(x)
> g[0] := a
> for i := 1 .. k - 1
> begin
> a := (a + b) MOD m
> b := (b + i) MOD m
> g[i] := a
> end
> end
>
> It's easy to see that the computation the enhanced double hash computes
>
> hash[i] = h1(x) + i * h2(x) + (i^3 - i) / 6
>
> if we use a=h1(x) and b=h2(x), generates the sequence:
>
> a, a + b, a + 2 * b + 1, a + 3 * b + 4, a + 4 * b + 10, ...
>
> And both your implementation and the wikipedia article generates
>
> a, a + b, a + 2 * b, a + 3 * b + 1, a + 4 * b + 4, ...
>
> So the last term in the sum lags one step behind.
>
> The solution, I think, is as simple as swapping the assignments of index
> and inc in your implementation.
>
> I suppose the impact of this is nil, but I'm not an expert for judging
> that.
>
> Thanks,
>
> Juan Manuel Gimeno
>

Re: [COLLECTIONS] Is the changes.xml file automatically updated by pull merge?

[Alex Herbert]

No. Just add it as a second commit after merge.

On Sun, 12 May 2024, 11:12 Claude Warren,  wrote:

> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>

Re: [Collections] Suppliers, Iterables, and Producers

[Alex Herbert]

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, ...


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


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

In the case of small loops with few instructions per loop, the overhead of
Streams is significant. Unfortunately we don't have any performance tests
for this library, but I wouldn't change to Streams without knowing it does
not impact performance. Performance is a key feature of Bloom filters.
Otherwise you can achieve some of their functionality with conventional
collections.


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

Re: [Collections] Suppliers, Iterables, and Producers

[Alex Herbert]

Hi Gary,

I am in favour of using nomenclature and patterns that will be familiar to
a Java developer. But only if they match the familiar JDK use patterns. The
Bloom filter package has some atypical use patterns that have driven the
current API to where it is. I'll try and describe these below.

On Sun, 28 Apr 2024 at 14:16, Gary Gregory  wrote:

> Hi Clause, Albert, and all,
>
> Since the introduction of lambdas in Java 8, Java has a well-defined
> terminology around the classic producer-consumer paradigm but (for
> reasons unknown to me) realized in the functional interfaces *Supplier
> and *Consumer. In addition, as of Java 5, we have the Iterable
> interface.
>
> In our new Bloom filter package we have new interfaces called
> *Producer (as opposed to *Supplier), where some of these new
> interfaces are formally annotated with @FunctionalInterface and some
> not (for example, BloomFilterProducer).
>
> My question is: Why call these "Producers" instead of "Suppliers"? Is
> the formal Bloom filter literature tied to the "Producer" terminology
> in a way that would make adapting to the Java term confusing? I know I
> brought up a similar topic recently, but I would like to revisit it
> now that I've started to read Claude's blog drafts. Even without
> making the current "Producers" formal suppliers by extending Supplier,
> would it be worth using the Java terminology?
>

Claude is familiar with the literature and can comment on that. I would
defer to the literature if it is a common term.

There is one notable distinction to JDK suppliers. Suppliers only supply 1
element and must be repeatedly called to generate more. The Producers in
the BloomFilter package will supply multiple values. They are invoked using
a forEach pattern with the intention of supplying all the elements to a
predicate, not a consumer. If any of those elements is rejected by the
predicate then the rest of the elements are not supplied. So this is a
fail-fast bulk supplier.


>
> My second observation is that some might neither be "Producers" or
> "Suppliers" but instead be extensions of Iterable. For example,
> BitMapProducer is not a factory for instances of BitMap; the BitMap
> does not appear in the signatures of BitMapProducer methods. From a
> strict Java POV, this is (slightly) perplexing.
>

Iterable was suggested in an earlier API, particular for the IndexProducer.
IIRC it was rejected on the basis of simplifying the code for the caller in
the fail-fast case. Otherwise every user of the iterator must implement
fail-fast loops over the elements. There may have been other reasons so it
could be worth a check in the mailing list archives. It would require going
back a few years but it was discussed on the dev list.

The term BitMap refers to a long that holds 64-consecutive indices as
either present or absent. You can consider the sequential bitmaps
containing all indices from [0, n) as the serialized state of a Bloom
filter with n bits. This is essentially a BitSet as you can see from the
SimpleBloomFilter implementation. This originally wrapped a BitSet; it was
converted to directly implement the required read/write bit functionality
on the grounds of performance (no memory reallocation; no index checks).

We do not have a BitMap class since we use a long primitive. A rename would
be to LongProducer causing a name clash with the JDK. Renaming to something
else is possible but I believe BitMap is a term from the literature.


>
> Instead (forgetting the class name issue for now), we could have:
>
> @FunctionalInterface
> public interface BitMapProducer extends Iterable {...}
>
> Which would let implementations define:
>
> Iterator iterator();
>
> Instead of:
>
> boolean forEachBitMap(LongPredicate predicate);
>

The BitMapProducer is not iterating LongPredicates. It is iterating longs
to be accepted by a single LongPredicate. The boolean return allows
signalling to stop the forEach loop. There is no primitive specialisation
of Iterator for long. There is a Spliterator.OfLong but that bundles some
other API that we do not wish to support, namely parallel streaming via
split and the ability to advance element by element (tryAdvance). Currently
we only implement the equivalent of the forEachRemaining pattern from
Spliterator. That accepts a consumer and so fail-fast would be done via
raising a runtime exception. Given that fail-fast is a key feature of a
Bloom filter then we do not want this to be implemented via exceptions.

The primary use case for fail-fast is to stop as soon as a bit index is
found, or not found (case dependent). Consider a Bloom filter that has 20
indices per hashed item. You have populated the filter with items, each has
20 random indices. You then check if a new item is not contained in the
filter by creating indices for the new item with your hash function and
checking each index against those already in the filter. If your new
element has an index not in the filter, then you have not seen this element
befo

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

[Alex Herbert]

On Thu, 25 Apr 2024 at 21:47, Gary D. Gregory  wrote:

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

I do not see any problems with this. However it may have little benefit
other than being consistent with the Java API. Once you have an
IndexProducer you typically put all the indices into a Bloom filter. But
you cannot construct a BloomFilter from an IndexProducer alone as you
require the Shape. So at present I cannot see a common use case for the
chaining methods (compose, apply) that come with the Function interface.

Alex

Re: [Collections-BloomFilter][Discuss] missing functionality?

[Alex Herbert]

On Sat, 20 Apr 2024 at 11:36, Claude Warren  wrote:

>  The LayerdBloomFilter has a method find() that returns an array of ints
> that are the indices into the layer array.  This is easily reproducible
> using an iterator.
> There is also get() method that takes an integer argument (an index of the
> bloom filter) and returns the Bloom filter from the layer.  This is
> reproducible but not as efficient using an iterator.
>

Note that using an iterator is how the LinkedList would do this. We are not
using an ArrayList with Order(1) retrieval time.
So performance of the current implementation here is already Order(n).


> I think the array is the proper structure.
>

If an array is the correct structure then we should type to List. Typing to
an interface allows changing the implementation with no effect on the API.
For example changing to a concurrent data structure.

The question is what is the most important functionality? Order(1) add and
remove from the head and tail of the layers (Deque) or Order(1) retrieval
of layers by depth index (List).

Re: find

It currently returns the layer index. What would you do with this other
than call get(index) to get the BloomFilter. We could support this with a
different find method:

// find each bloom filter layer that contains the IndexProducer
// API can be changed if this is required to return as soon as a filter is
found that satisfies some requirement (Predicate vs Consumer).
public void findEach(IndexProducer indexProducer, Consumer
result)

Why else do you require indices of layers? If there is no use case
other than layer retrieval then this seems to be the wrong API.

Alex



> Claude
>
> On Fri, Apr 19, 2024 at 11:06 AM Alex Herbert 
> wrote:
>
> > On Fri, 19 Apr 2024 at 08:26, Claude Warren  wrote:
> >
> > > While the Deque makes clear the idea of enqueueing and dequeueing  the
> > > layers it does not have the method to natively traverse and extract
> > entries
> > > from the middle of the queue.  Nor would I expect it to.  So I think
> the
> > > Deque does not accurately reflect how the collection of Bloom filters
> is
> > > utilized.
> > >
> >
> > You can traverse and remove entries with the Iterator of the Deque:
> >
> > Deque d = new LinkedList<>();
> > d.addAll(Arrays.asList(1, 2, 3, 4, 5));
> > for (Iterator it = d.iterator(); it.hasNext();) {
> > int i = it.next();
> > if (i == 3) {
> > it.remove();
> > }
> > }
> > System.out.println(d);
> >
> > prints:
> >
> > [1, 2, 4, 5]
> >
> > So it is easy to iterate the layers and remove them in Order(1) time (per
> > removal).
> >
> > Alex
> >
> >
> > >
> > > On Wed, Apr 17, 2024 at 2:17 PM Alex Herbert  >
> > > wrote:
> > >
> > > > Looks good to me.
> > > >
> > > > Any opinions on changing the LayerManager to keep the layers in a
> Deque
> > > > rather than a LinkedList. I think it would only require a change to
> the
> > > > following method:
> > > >
> > > > public final BloomFilter get(int depth)
> > > >
> > > > Performance will be the same as the Deque can be a LinkedList. This
> is
> > > more
> > > > about how any custom downstream code is currently using the
> collection
> > of
> > > > layers.
> > > >
> > > > Alex
> > >
> > >
> >
>
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>

Re: [Collections-BloomFilter][Discuss] missing functionality?

[Alex Herbert]

On Fri, 19 Apr 2024 at 08:26, Claude Warren  wrote:

> While the Deque makes clear the idea of enqueueing and dequeueing  the
> layers it does not have the method to natively traverse and extract entries
> from the middle of the queue.  Nor would I expect it to.  So I think the
> Deque does not accurately reflect how the collection of Bloom filters is
> utilized.
>

You can traverse and remove entries with the Iterator of the Deque:

Deque d = new LinkedList<>();
d.addAll(Arrays.asList(1, 2, 3, 4, 5));
for (Iterator it = d.iterator(); it.hasNext();) {
int i = it.next();
if (i == 3) {
it.remove();
}
}
System.out.println(d);

prints:

[1, 2, 4, 5]

So it is easy to iterate the layers and remove them in Order(1) time (per
removal).

Alex


>
> On Wed, Apr 17, 2024 at 2:17 PM Alex Herbert 
> wrote:
>
> > Looks good to me.
> >
> > Any opinions on changing the LayerManager to keep the layers in a Deque
> > rather than a LinkedList. I think it would only require a change to the
> > following method:
> >
> > public final BloomFilter get(int depth)
> >
> > Performance will be the same as the Deque can be a LinkedList. This is
> more
> > about how any custom downstream code is currently using the collection of
> > layers.
> >
> > Alex
>
>

Re: [Collections-BloomFilter][Discuss] missing functionality?

[Alex Herbert]

Looks good to me.

Any opinions on changing the LayerManager to keep the layers in a Deque
rather than a LinkedList. I think it would only require a change to the
following method:

public final BloomFilter get(int depth)

Performance will be the same as the Deque can be a LinkedList. This is more
about how any custom downstream code is currently using the collection of
layers.

Alex

On Wed, 17 Apr 2024 at 10:00, Claude Warren  wrote:

> I have an open pull request to fix this problem.  I could use another
> review: https://github.com/apache/commons-collections/pull/476
>
>
> On Tue, Apr 9, 2024 at 11:29 AM Claude Warren  wrote:
>
> > Alex,
> >
> > I like your solution.  To answer your question. We create a BloomFilter
> > that has a timestamp associated with it.  When the timestamp is greater
> > than System.currentTimeMillis() the filter is removed.  The custom
> cleanup
> > calls Cleanup.removeEmptyTarget().andThen()
> >
> > I think that creating a cleanup() or clean() method on the
> > LayeredBloomFilter is the appropriate solution and that it should call
> > cleanup() on the LayerManager. (so 2 new methods, one exposed).
> >
> > The next() method is used when external circumstances dictate that a new
> > layer should be created.  I think a StableBloomFilter I implemented
> > required it,  but I do not have the code to hand at the moment.
> >
> > Claude
> >
> >
> > On Tue, Apr 9, 2024 at 10:38 AM Alex Herbert 
> > wrote:
> >
> >> Hi Claude,
> >>
> >> Q. What is your current clean-up filter, i.e.
> >> the Consumer>? I assume you are using a custom
> >> one.
> >>
> >> The current collections code only has 2 functional implementations. One
> >> will remove the newest filter if it is empty, one will remove the oldest
> >> filters until the size is below a limit. Since neither of those will
> >> iterate the list and purge stale objects then I assume you are using a
> >> custom clean-up filter. So you had to have created the layer manager
> with
> >> your custom filter. Assuming this then there are at least two solutions
> >> for
> >> the current code:
> >>
> >> 1. The current implementation always calls the clean-up filter with the
> >> same LinkedList since it is final. So you can capture the list and do
> what
> >> you want with it:
> >>
> >> @SuppressWarnings("rawtypes")
> >> LinkedList[] captured = new LinkedList[1];
> >> Consumer> cleanup = list -> {
> >> captured[0] = list;
> >> // ... do clean-up
> >> };
> >>
> >> // Once you have captured the list, you can clean it when you
> >> want:
> >> // unchecked conversion
> >> cleanup.accept(captured[0]);
> >>
> >> Obviously this is not ideal as you have to manage the captured list to
> >> call
> >> cleanup. But it delivers exactly what you require in terms of being able
> >> to
> >> call cleanup at any time.
> >>
> >> 2. The call to next() will clean the layers but also add a new layer. So
> >> your custom clean method could clean stale objects and also any empty
> >> filters not at the end of the list. This will avoid building up lots of
> >> empty filters when you frequently trigger next() to purge stale filters.
> >> You can call next() directly on the LayeredBloomFilter. I do not know
> what
> >> extend check you are using so there is some management to be done with
> the
> >> other settings of the LayerManager to avoid removing any functional
> layers
> >> which are currently empty.
> >>
> >> --
> >>
> >> As to exposing the LayerManager and adding a clean() method to the
> >> LayerManager, I think this is not in keeping with the current design.
> The
> >> LayerManager is used during construction and then never used again. So
> >> functionality to act on the layers is public through the
> >> LayeredBloomFilter
> >> (e.g. calling next()). So perhaps the change to the API should be to
> add a
> >> cleanup() method to LayeredBloomFilter. This does the same as next(),
> but
> >> does not add a new layer.
> >>
> >> I cannot recall the use case for next() in the LayeredBloomFilter. Would
> >> the addition of cleanup() make the next() method redundant?
> >>
> >> --
> >>
> >> Note: The typing against LinkedList could be updated to java.ut

Re: [Collections-BloomFilter][Discuss] missing functionality?

[Alex Herbert]

Hi Claude,

Q. What is your current clean-up filter, i.e.
the Consumer>? I assume you are using a custom one.

The current collections code only has 2 functional implementations. One
will remove the newest filter if it is empty, one will remove the oldest
filters until the size is below a limit. Since neither of those will
iterate the list and purge stale objects then I assume you are using a
custom clean-up filter. So you had to have created the layer manager with
your custom filter. Assuming this then there are at least two solutions for
the current code:

1. The current implementation always calls the clean-up filter with the
same LinkedList since it is final. So you can capture the list and do what
you want with it:

@SuppressWarnings("rawtypes")
LinkedList[] captured = new LinkedList[1];
Consumer> cleanup = list -> {
captured[0] = list;
// ... do clean-up
};

// Once you have captured the list, you can clean it when you want:
// unchecked conversion
cleanup.accept(captured[0]);

Obviously this is not ideal as you have to manage the captured list to call
cleanup. But it delivers exactly what you require in terms of being able to
call cleanup at any time.

2. The call to next() will clean the layers but also add a new layer. So
your custom clean method could clean stale objects and also any empty
filters not at the end of the list. This will avoid building up lots of
empty filters when you frequently trigger next() to purge stale filters.
You can call next() directly on the LayeredBloomFilter. I do not know what
extend check you are using so there is some management to be done with the
other settings of the LayerManager to avoid removing any functional layers
which are currently empty.

--

As to exposing the LayerManager and adding a clean() method to the
LayerManager, I think this is not in keeping with the current design. The
LayerManager is used during construction and then never used again. So
functionality to act on the layers is public through the LayeredBloomFilter
(e.g. calling next()). So perhaps the change to the API should be to add a
cleanup() method to LayeredBloomFilter. This does the same as next(), but
does not add a new layer.

I cannot recall the use case for next() in the LayeredBloomFilter. Would
the addition of cleanup() make the next() method redundant?

--

Note: The typing against LinkedList could be updated to java.util.Deque.
The only issue with this is the method:
public final BloomFilter get(int depth)

This is not supported by the Deque interface. However the LinkedList
implementation of get(int) will use the iterator from the start or end of
the list (whichever is closer) to find the element. This can use the
iterator/descendingIterator method of Deque for the same performance (but
the code to do this has to be written).

Alex


On Tue, 9 Apr 2024 at 08:45, Claude Warren  wrote:

> Greetings,
>
> I am attempting to use the Bloomfilter code in Kafka to manage PID
> generation.  The requirement is to remove pid tracking after a period of
> time.  This is possible with the LayeredBloomFilter but it has an edge case
> problem.
>
> The LayeredBloomFilter uses the LayerManager to manage the filters that
> comprise the layers of the LayerdBloomFilter.
> The LayerManager uses a Consumer> called
> filterCleanup to remove old layers.
> The filterCleanup is only called when a new layer is added to the layered
> filter.
>
> This solution works well in the general case where data is flowing through
> the layered filter.  However if nothing is added to the filter,
> filterCleanup is not called.
>
> In the Kafka case we have a LayeredBloomFilter for PIDs for each producer.
> As long as a producer is producing PIDs the filter gets updated.
>
> However, if a producer drops from the system or goes offline for a period
> of time, then they will no longer be producing PIDs and their old expired
> data will remain.
>
> We want to remove the producer from the collection when there are no more
> PIDs being tracked.
>
> I think this can be solved by adding a clean() method to the LayerManager
> that simply calls the existing filterCleanup.
> It would be easier to access this method if the LayeredBloomFilter had a
> method to return the LayerManager that was passed in the constructor.
>
> Does anyone see any issues with this approach?  Are there other solutions
> to be had?
>
> Questions and comments welcomed.
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>

Re: [Collections] New release candidate for 4.5.0-beta1 or -M1 and new Bloom Filter package

[Alex Herbert]

On Mon, 25 Mar 2024 at 13:12, Gary Gregory  wrote:

> Hi All,
>
> 4.5.0 will contain a new package for Bloom Filters.
>
> Since this is a new package and is non-trivial, I propose we release a
> version called 4.5.0-M1 or 4.5.0-beta1 to let users try this out while
> giving us the change to make breaking API changes if needed.
>
> Gary
>

+1

I have not looked at the Bloom filter package for a while. It is on my todo
list to check the API is consistently and correctly implemented by the
underlying classes.

The package also does not have any performance tests. It would be nice to
have some since Bloom filters are probabilistic structures that offer
speed-up over other data structures to track occurrences of objects whilst
compromising on the exactness of results, i.e they are configured with a
desired false-positive rate. At present the code is rather complex and it
would be nice to have some figures to show the advantages.

We should also get some closure on COLLECTIONS-842 [1] which is an
incompatibility between collections and default methods added to List in
JDK 21. I looked at this for a while but did not change anything in the
codebase. TLDR: you cannot compile collections with JDK 21 but you can run
it with JDK 21 if the binary is compiled for an earlier target. It affects
any class extending AbstractLinkedList (there are 3 in Collections). The
minimum effort would be to mark the AbstractLinkedList methods as
deprecated and in future to be changed to the same API as JDK 21. This
would leave the 4.X branch compile time limited to LTS JDKs up to 17.

Alex

[1] https://issues.apache.org/jira/browse/COLLECTIONS-842

Re: [Net] JUnit 5 migration discussion

[Alex Herbert]

Use of abstract classes does work in JUnit 5. I've written a lot of JUnit 5
tests that use abstract test classes which define the
@ParameterizedTest/@Test fixtures and then concrete child classes that are
run by the framework. It is supported but IIRC it is not recommended in the
JUnit 5 documentation. It has been a while since I looked to see
what alternatives are provided.

IMO the use of an abstract base class that has all the tests is still a
useful pattern. It is used in Commons Collections for the Bloom filter
package to test that implementations of the BloomFilter interfaces all
provide the required functionality. A more convoluted abstract test class
structure is used in Commons Statistics in the distribution and descriptive
packages. These abstract classes define methods to test interface
implementations. The child classes then provide instances of the interface
to test with standard data, and can provide custom data to test them with.
I do not think it is as configurable to have a single class with
@ParameterizedTest methods to test lots of different implementations. It
requires a very large method to stream all the different instances to test
and their data. This pattern is used in Commons RNG to test instances of a
random generator interface, or distribution samplers.

A quick browse of the API finds @TestTemplate which requires registering
providers and a lot more setup. Note that @ParameterizedTest is a built-in
specialization of @TestTemplate. So this is a JUnit5 way to create more
configurable tests which provide combinations of parameters for the test.

I found that using an abstract class I was able to create a test framework
that tested what was required and allowed testing of each implementation
individually. So I could do what I wanted. However I cannot state if it
would be better with @TestTemplate or some other JUnit 5 way to achieve the
same result. I remember trying a few other options but cannot remember why
I gave up and resorted to the abstract class pattern.

Note that it would be better to have VFS on JUnit 5 using abstract classes
than on JUnit 3 or 4. I would try and upgrade one test and see if it works.

Alex


On Thu, 29 Feb 2024 at 20:43, Gary Gregory  wrote:

> Thank you for digging into this Eric.
>
> Another component to consider for JUnit 5 migration is Commons VFS. This
> one is challenging due to some similar JUnit 3 and 4 heritage issues.
>
> It is possible that between Net and VFS, what we need are custom JUnit
> extensions. I had started a Commons Testing repository a long time ago but
> never got far with adding what at the time were JUnit 4 rules.
>
> I too find some of the JUnit 5 changes baffling but that's what we got...
> unless we want to switch to TextNG or some other test framework which would
> be a big change.
>
> Gary
>
>
> On Thu, Feb 29, 2024, 3:13 PM Elric V  wrote:
>
> > Hi folks,
> >
> > I recently made some changes to commons-cli to move it from JUnit 4 to
> > JUnit 5. This was mostly straightforward, and I think it went pretty
> well.
> >
> > Currently looking into doing the same for commons-net, but there are a
> > couple of tricky tests that probably require some up front discussion,
> > mostly JUnit 3 style tests, and one tricky JUnit 4 Parameterized Test.
> >
> > In previous versions, test classes could be extended and their test
> > methods would be executed as part of the child class' execution. This
> > was true for testt methods annotated with JUnit 4's @Test, or JUnit 3's
> > test-prefix naming convention.
> >
> > Unfortunately, this is no longer the case in JUnit 5. I think this is a
> > poor design decision on their part, as it makes it significantly harder
> > to move to JUnit 5, and it makes certain types of tests just plain
> > difficult. There is some discussion about this in the JUnit community
> > [1], but I can't predict whether this will ever be resolved in a way to
> > makes commons-net's upgrade any easier.
> >
> > One of those cases is AbstractFTPParseTest and its children. This
> > abstract base class has 11 concrete test classes. I'm struggling to see
> > a minimally invasive way to migrate these to JUnit 5. I'm loath to use a
> > heavy handed approach there.
> >
> > A second tricky case is FTPSClientTest, which is a Parameterized test of
> > a form that no longer exists in JUnit 5. It basically creates two
> > instances of a test class with a boolean flag (once true, once false).
> >
> > JUnit 5's @ParameterizedTest annotation operates on the **test method**
> > level, not on the class level, which I think would make the test case
> > slower and harded to read.
> >
> > An alternative approach would be to use Dynamic Tests, which basically
> > generate test cases programmatically, but again, that makes grokking the
> > test a lot more difficult as it requires a greater understanding of
> > JUnit's features.
> >
> > Any insights into this would be greatly appreciated.
> >
> > Best,
> >
> > Elric
> >
> > [1] https://github

Re: New to community-Introducing myself

[Alex Herbert]

On Sun, 31 Dec 2023 at 20:54, Narasimha asuri
 wrote:
>
> Hi,
>
> Chary here, I am a beginner java developer and I used many components
> of Apache commons library in my previous project, Lang, IO, Math. Saw the
> commons - math library and am on looking to help solve some issues.
>
>
>
> Chary.

Welcome.

You can find all of the Commons components from the homepage [1].

Each Commons component has its own Jira tracker for issues [2]. Please
look at the component you are interested in to see outstanding issues
and find ideas for issues to work on. The README in the component
repository (mirrored through GitHub) has a link to the relevant Jira
project, e.g. [3, 4], or you can find it from the component homepage
under the 'Issue Management' section [5].

Any discussion on development for a specific component can be started
as a discussion on this mailing list using the component as a message
subject prefix in square brackets, e.g. [math] my idea is ...

Alex

[1] https://commons.apache.org/
[2] https://issues.apache.org/jira
[3] https://github.com/apache/commons-math
[4] https://issues.apache.org/jira/projects/MATH
[5] https://commons.apache.org/proper/commons-math/issue-management.html

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

Re: (commons-numbers) branch master updated: Simplify conversion of numbers to unsigned

[Alex Herbert]

On Sun, 24 Dec 2023 at 17:51, sebb  wrote:
>
> On Sun, 24 Dec 2023 at 16:58,  wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > aherbert pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-numbers.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >  new a15b3e68 Simplify conversion of numbers to unsigned
> > a15b3e68 is described below
> >
> > commit a15b3e68136dd94ea20e4085afc45aa73d46362e
> > Author: Alex Herbert 
> > AuthorDate: Sun Dec 24 16:57:58 2023 +
> >
> > Simplify conversion of numbers to unsigned
> > ---
> >  .../java/org/apache/commons/numbers/core/ArithmeticUtilsTest.java | 8 
> > ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git 
> > a/commons-numbers-core/src/test/java/org/apache/commons/numbers/core/ArithmeticUtilsTest.java
> >  
> > b/commons-numbers-core/src/test/java/org/apache/commons/numbers/core/ArithmeticUtilsTest.java
> > index 4063f440..0b4aa797 100644
> > --- 
> > a/commons-numbers-core/src/test/java/org/apache/commons/numbers/core/ArithmeticUtilsTest.java
> > +++ 
> > b/commons-numbers-core/src/test/java/org/apache/commons/numbers/core/ArithmeticUtilsTest.java
> > @@ -28,6 +28,8 @@ import org.junit.jupiter.api.Test;
> >   *
> >   */
> >  class ArithmeticUtilsTest {
> > +/** 2^63. */
> > +private static final BigInteger TWO_POW_63 = 
> > BigInteger.ONE.shiftLeft(63);
> >
> >  @Test
> >  void testGcd() {
> > @@ -538,7 +540,7 @@ class ArithmeticUtilsTest {
> >  }
> >
> >  private static long toUnsignedLong(int number) {
> > -return number < 0 ? 0x1L + (long)number : (long)number;
> > +return Integer.toUnsignedLong(number);
> >  }
>
> The private method could now be dropped.

I did this, then reverted. IMO it creates more noise in the source
where the method is called as it must be prefixed by "Integer.". This
makes one-liner code go over 120 chars.


>
> >  private static int remainderUnsignedExpected(int dividend, int 
> > divisor) {
> > @@ -550,7 +552,9 @@ class ArithmeticUtilsTest {
> >  }
> >
> >  private static BigInteger toUnsignedBigInteger(long number) {
> > -return number < 0L ? 
> > BigInteger.ONE.shiftLeft(64).add(BigInteger.valueOf(number)) : 
> > BigInteger.valueOf(number);
> > +return number < 0 ?
> > +TWO_POW_63.or(BigInteger.valueOf(number & Long.MAX_VALUE)) :
> > +BigInteger.valueOf(number);
> >  }
> >
> >  private static long remainderUnsignedExpected(long dividend, long 
> > divisor) {
> >
>
> -
> 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: [MATH][NUMBERS] Method to convert unsigned long to BigInteger

[Alex Herbert]

On Sun, 24 Dec 2023 at 16:31, sebb  wrote:
>
> On Sun, 24 Dec 2023 at 16:14, Alex Herbert  wrote:
> >
> > On Sun, 24 Dec 2023 at 13:58, sebb  wrote:
> > >
> > > On Sun, 24 Dec 2023 at 13:16, Alex Herbert  
> > > wrote:
> > > >
> > > > On Sun, 24 Dec 2023 at 11:45, Elliotte Rusty Harold 
> > > >  wrote:
> > > > >
> > > > > On Sun, Dec 24, 2023 at 9:59 AM sebb  wrote:
> > > > > >
> > > > > > Both Numbers and Statistics have implementations of
> > > > > >
> > > > > > BigInteger toUnsignedBigInteger(long treatedAsUnsigned)
> > > > > >
> > > > >
> > > > > Can you describe a use case for this? That might help decide where it
> > > > > belongs. I wouldn't be surprised if this is more suitable for lang
> > > > > than Math or Numbers.
> > > > >
> > > > > I'd also suggest a different method name. There's no such thing as an
> > > > > UnsignedBigInteger in Java. All BigIntegers are signed. Maybe
> > > > > something like toBigIntegerFromUnsigned
> > > >
> > > > The method is effectively (but without expensive string conversions):
> > > >
> > > > new BigInteger(Long.toUnsignedString(v));
> > > >
> > > > I do not have a use case for it other than testing unsigned integer
> > > > math implementations. It could be used to create a valid number when
> > > > using a long counter that has overflowed to negative.
> > > >
> > > > A possible home is in [Lang]:
> > > >
> > > > org.apache.commons.lang3.math.NumberUtils
> > > >
> > > > That class has some conversion methods to BigDecimal for
> > > > floating-point numbers with rounding to a number of significant
> > > > digits. So creating BigInteger beyond the support of the JDK methods
> > > > is in scope.
> > > >
> > > > Without a use case it would just be code bloat.
> > >
> > > If it were added to MATH, the implementations could be dropped from
> > > NUMBERS and STATISTICS...
> >
> > Math depends on Numbers and Statistics. So that would be a circular 
> > dependency.
> >
> > It is a simple two line method. I think this is fine duplicated across
> > test codebases.
>
> I've just noticed that the methods are slightly different.
> One uses add, the other or and a mask.
>
> Numbers:
> return number < 0L ?
> BigInteger.ONE.shiftLeft(64).add(BigInteger.valueOf(number)) :
> BigInteger.valueOf(number);
>
> Statistics:
> return v < 0 ? TWO_POW_63.or(BigInteger.valueOf(v & Long.MAX_VALUE)) :
> BigInteger.valueOf(v);

Yes. I wrote the one with the or method today as I realised my
original using the add was not required. Here we are combining
non-overlapping bits. Doing an add will create the same result. But it
will do extra work to compute the carry (of zero) up through the
number.

E.g.

a000 + 0bcd = abcd
a000 | 0bcd = abcd

I'll update the original.

>
> > We could make the method public in the Numbers test class and have the
> > relevant test Statistics code depend on the Numbers test jar. But that
> > seems overly convoluted for the simple method.
>
> > 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
>

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

Re: [MATH][NUMBERS] Method to convert unsigned long to BigInteger

[Alex Herbert]

On Sun, 24 Dec 2023 at 13:58, sebb  wrote:
>
> On Sun, 24 Dec 2023 at 13:16, Alex Herbert  wrote:
> >
> > On Sun, 24 Dec 2023 at 11:45, Elliotte Rusty Harold  
> > wrote:
> > >
> > > On Sun, Dec 24, 2023 at 9:59 AM sebb  wrote:
> > > >
> > > > Both Numbers and Statistics have implementations of
> > > >
> > > > BigInteger toUnsignedBigInteger(long treatedAsUnsigned)
> > > >
> > >
> > > Can you describe a use case for this? That might help decide where it
> > > belongs. I wouldn't be surprised if this is more suitable for lang
> > > than Math or Numbers.
> > >
> > > I'd also suggest a different method name. There's no such thing as an
> > > UnsignedBigInteger in Java. All BigIntegers are signed. Maybe
> > > something like toBigIntegerFromUnsigned
> >
> > The method is effectively (but without expensive string conversions):
> >
> > new BigInteger(Long.toUnsignedString(v));
> >
> > I do not have a use case for it other than testing unsigned integer
> > math implementations. It could be used to create a valid number when
> > using a long counter that has overflowed to negative.
> >
> > A possible home is in [Lang]:
> >
> > org.apache.commons.lang3.math.NumberUtils
> >
> > That class has some conversion methods to BigDecimal for
> > floating-point numbers with rounding to a number of significant
> > digits. So creating BigInteger beyond the support of the JDK methods
> > is in scope.
> >
> > Without a use case it would just be code bloat.
>
> If it were added to MATH, the implementations could be dropped from
> NUMBERS and STATISTICS...

Math depends on Numbers and Statistics. So that would be a circular dependency.

It is a simple two line method. I think this is fine duplicated across
test codebases.

We could make the method public in the Numbers test class and have the
relevant test Statistics code depend on the Numbers test jar. But that
seems overly convoluted for the simple method.

Alex

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

Re: (commons-numbers) 01/01: Use Java 1.8 methods to simplify the ArithmeticUtils methods remainderUnsigned and divideUnsigned (both int and long)

[Alex Herbert]

I would be wary of this simplification without a performance test.

In the Numbers class the int methods do not use long arithmetic. The
long methods do not use BigInteger. This is unlike those methods in my
JDK 8 source code which do and are likely much slower. A quick check
in JDK 21 finds this is still not an intrinsic method [1]. My only
issue with the Numbers methods is they are based on the Hacker's
Delight book which is not free, thus it is not easy to check the
implementation against the source.

Alex

[1] https://chriswhocodes.com/hotspot_intrinsics_openjdk21.html

On Sun, 24 Dec 2023 at 13:20,  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> sebb pushed a commit to branch java8-simplify
> in repository https://gitbox.apache.org/repos/asf/commons-numbers.git
>
> commit 2f60d424725ca619abf324858593368e66dd5fc2
> Author: Sebb 
> AuthorDate: Sun Dec 24 13:20:13 2023 +
>
> Use Java 1.8 methods to simplify the ArithmeticUtils methods 
> remainderUnsigned and divideUnsigned (both int and long)
> ---
>  .../commons/numbers/core/ArithmeticUtils.java  | 68 
> +++---
>  src/changes/changes.xml|  3 +
>  2 files changed, 11 insertions(+), 60 deletions(-)
>
> diff --git 
> a/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/ArithmeticUtils.java
>  
> b/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/ArithmeticUtils.java
> index d34d7e2b..7afde103 100644
> --- 
> a/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/ArithmeticUtils.java
> +++ 
> b/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/ArithmeticUtils.java
> @@ -470,7 +470,7 @@ public final class ArithmeticUtils {
>   * Returns the unsigned remainder from dividing the first argument
>   * by the second where each argument and the result is interpreted
>   * as an unsigned value.
> - * This method does not use the {@code long} datatype.
> + * This method uses the Java 1.8+ method {@link 
> Integer#remainderUnsigned(int, int)}.
>   *
>   * @param dividend the value to be divided
>   * @param divisor the value doing the dividing
> @@ -478,27 +478,14 @@ public final class ArithmeticUtils {
>   * the second argument.
>   */
>  public static int remainderUnsigned(int dividend, int divisor) {
> -if (divisor >= 0) {
> -if (dividend >= 0) {
> -return dividend % divisor;
> -}
> -// The implementation is a Java port of algorithm described in 
> the book
> -// "Hacker's Delight" (section "Unsigned short division from 
> signed division").
> -final int q = ((dividend >>> 1) / divisor) << 1;
> -dividend -= q * divisor;
> -if (dividend < 0 || dividend >= divisor) {
> -dividend -= divisor;
> -}
> -return dividend;
> -}
> -return dividend >= 0 || dividend < divisor ? dividend : dividend - 
> divisor;
> +return Integer.remainderUnsigned(dividend, divisor);
>  }
>
>  /**
>   * Returns the unsigned remainder from dividing the first argument
>   * by the second where each argument and the result is interpreted
>   * as an unsigned value.
> - * This method does not use the {@code BigInteger} datatype.
> + * This method uses the Java 1.8+ method {@link 
> Long#remainderUnsigned(int, int)}.
>   *
>   * @param dividend the value to be divided
>   * @param divisor the value doing the dividing
> @@ -506,20 +493,7 @@ public final class ArithmeticUtils {
>   * the second argument.
>   */
>  public static long remainderUnsigned(long dividend, long divisor) {
> -if (divisor >= 0L) {
> -if (dividend >= 0L) {
> -return dividend % divisor;
> -}
> -// The implementation is a Java port of algorithm described in 
> the book
> -// "Hacker's Delight" (section "Unsigned short division from 
> signed division").
> -final long q = ((dividend >>> 1) / divisor) << 1;
> -dividend -= q * divisor;
> -if (dividend < 0L || dividend >= divisor) {
> -dividend -= divisor;
> -}
> -return dividend;
> -}
> -return dividend >= 0L || dividend < divisor ? dividend : dividend - 
> divisor;
> +return Long.remainderUnsigned(dividend, divisor);
>  }
>
>  /**
> @@ -531,7 +505,7 @@ public final class ArithmeticUtils {
>   * bit-wise identical if the two operands are regarded as both
>   * being signed or both being unsigned. Therefore separate {@code
>   * addUnsigned}, etc. methods are not provided.
> - * This method does not use the {@code long} datatype.
> + * This method uses the Java 1.8+ method {@link 
> Integer#divideUnsigned(int, int)}.
>   *
>   * @param dividend the value to be di

Re: (commons-numbers) branch java8-simplify created (now 2f60d424)

[Alex Herbert]

On Sun, 24 Dec 2023 at 13:20,  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> sebb pushed a change to branch java8-simplify
> in repository https://gitbox.apache.org/repos/asf/commons-numbers.git
>
>
>   at 2f60d424 Use Java 1.8 methods to simplify the ArithmeticUtils 
> methods remainderUnsigned and divideUnsigned (both int and long)
>
> This branch includes the following new commits:
>
>  new 2f60d424 Use Java 1.8 methods to simplify the ArithmeticUtils 
> methods remainderUnsigned and divideUnsigned (both int and long)
>
> The 1 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails.  The revisions
> listed as "add" were already present in the repository and have only
> been added to this reference.

I would be wary of this simplification without a performance test.

In the Numbers class the int methods do not use long arithmetic. The
long methods do not use BigInteger. This is unlike those methods in my
JDK 8 source code which do and are likely much slower. A quick check
in JDK 21 finds this is still not an intrinsic method [1]. My only
issue with the Numbers methods is they are based on the Hacker's
Delight book which is not free, thus it is not easy to check the
implementation against the source.

Alex

[1] https://chriswhocodes.com/hotspot_intrinsics_openjdk21.html

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

Re: [MATH][NUMBERS] Method to convert unsigned long to BigInteger

[Alex Herbert]

On Sun, 24 Dec 2023 at 11:45, Elliotte Rusty Harold  wrote:
>
> On Sun, Dec 24, 2023 at 9:59 AM sebb  wrote:
> >
> > Both Numbers and Statistics have implementations of
> >
> > BigInteger toUnsignedBigInteger(long treatedAsUnsigned)
> >
>
> Can you describe a use case for this? That might help decide where it
> belongs. I wouldn't be surprised if this is more suitable for lang
> than Math or Numbers.
>
> I'd also suggest a different method name. There's no such thing as an
> UnsignedBigInteger in Java. All BigIntegers are signed. Maybe
> something like toBigIntegerFromUnsigned

The method is effectively (but without expensive string conversions):

new BigInteger(Long.toUnsignedString(v));

I do not have a use case for it other than testing unsigned integer
math implementations. It could be used to create a valid number when
using a long counter that has overflowed to negative.

A possible home is in [Lang]:

org.apache.commons.lang3.math.NumberUtils

That class has some conversion methods to BigDecimal for
floating-point numbers with rounding to a number of significant
digits. So creating BigInteger beyond the support of the JDK methods
is in scope.

Without a use case it would just be code bloat.

Alex

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

Re: [ALL] Deploying SNAPSHOTS from GH workflows

[Alex Herbert]

On Wed, 20 Dec 2023 at 17:15, sebb  wrote:
>
> Numbers is now deploying OK, as does Crypto.

I cannot see anything in the GH action config that specifies that
deploy should be only on the master/main branch in the original Apache
repo.

How is the deploy goal handled in forked repos and subsequently PRs?

Alex

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

Re: [NUMBERS] GH deploy snapshot test

[Alex Herbert]

On Wed, 20 Dec 2023 at 13:19, sebb  wrote:
>
> On Tue, 19 Dec 2023 at 16:08, Alex Herbert  wrote:
> >
> > Thanks Sebb,
> >
> > Note that previously the GH action was running the default goal:
> > 'clean verify javadoc:javadoc'.
> >
> > Since we now need to specify the 'deploy' goal as well the above
> > defaults can be switched in for your additions when Infra have created
> > the credentials.
>
> I added javadoc:javadoc to the goals, but I left out the verify goal
> as it should be part of deploy.
>
> The build mostly succeeded, but the BOM module failed, as it requires
> a GPG secret key.
> Is that needed for SNAPSHOT builds?

TLDR; No. Try '-Dgpg.skip'.

The BOM module is a bit of a fudge to create a minimal BOM. It would
be nice if this has a dedicated plugin to build a bom with some more
control over build and deploy. As it is I had to do a lot of Maven
config to get it to work.

It looks like the GPG profiles are being activated by presence/absence
of the gpg.skip property. Since this is for a snapshot deployment it
should work if you update the maven goal to include '-Dgpg.skip'.

Alex


>
> > Alex
> >
> > On Tue, 19 Dec 2023 at 14:29, sebb  wrote:
> > >
> > > Created https://issues.apache.org/jira/browse/INFRA-25297 to get
> > > access to credentials
> > >
> > > Added code to maven.yml to deploy the snapshot (needs to be enabled
> > > when creds are granted)
> > >
> > > -
> > > 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: [NUMBERS] GH deploy snapshot test

[Alex Herbert]

Thanks Sebb,

Note that previously the GH action was running the default goal:
'clean verify javadoc:javadoc'.

Since we now need to specify the 'deploy' goal as well the above
defaults can be switched in for your additions when Infra have created
the credentials.

Alex

On Tue, 19 Dec 2023 at 14:29, sebb  wrote:
>
> Created https://issues.apache.org/jira/browse/INFRA-25297 to get
> access to credentials
>
> Added code to maven.yml to deploy the snapshot (needs to be enabled
> when creds are granted)
>
> -
> 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: [ALL] Deploying SNAPSHOTS from GH workflows

[Alex Herbert]

On Tue, 19 Dec 2023 at 10:41, sebb  wrote:
>
> Crypto now has a workflow [4] that deploys a SNAPSHOT version.
>
> I don't know if we want to do this for all components, but if so, the
> process is:
> - raise INFRA Jira to request access to the secrets that hold the
> credentials [1]
> - use the java-settings action to create a settings.xml which
> references the variables holding the credentials [2]
> - pass the secrets as environment variables in the job-step that needs
> them [3] (Note:: we don't need the GPG variable)
>
> The Crypto workflow is rather complicated because it needs to build
> the code on several different OSes and then piece the bits together.
> Other components will be much simpler.
>
> Are there any other components that would benefit from/need snapshots?

Multi-module components are useful to deploy as snapshots if modules
depend on each other. This allows a developer to perform maven build
tasks in the module directory for the code they are working on. Maven
will download the latest snapshot for all the dependencies on other
component modules. It also allows a component to use a snapshot
dependency on another component outside the repo. This allows two
components to be developed in parallel without the developers having
to perform local installs for each change in the main branch.

Snapshots are deployed for the RNG, Statistics, Numbers, Math and
Geometry components via Jenkins running at ci-builds.apache.org. The
use of snapshots was very useful when bugs in Numbers were found when
developing Statistics. The bugs could be fixed in the Numbers snapshot
and Statistics developers automatically obtained the fix. When dev
work is complete the components can be released in order and SNAPSHOT
dependencies removed.

One advantage of the Jenkins set-up is that builds can be triggered by
builds in other repos. We have configured downstream projects to build
when the upstream project is updated. However this has yet to discover
an incompatibility or bug in downstream projects in the 4+ years they
have been running. So this feature is not essential.

I would be happy to trial a simpler (than Crypto) deploy of snapshots
using GH for one of these components, e.g. Numbers/RNG which have no
dependencies.

Alex

>
> Sebb
> [1] e.g. https://issues.apache.org/jira/browse/INFRA-25296
> [2] https://github.com/actions/setup-java#maven-options
> [3] 
> https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#yaml-example
> [4] 
> https://github.com/apache/commons-crypto/blob/master/.github/workflows/maven_crosstest.yml
>
> -
> 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: Apache Common Lang -- How do I compile or did I find a bug

[Alex Herbert]

On Tue, 12 Dec 2023 at 13:20, Gary Gregory  wrote:
>
> What's the best way to document this do you think?

That lang is tested (and so should be built) with the latest JDK of
the respective stable release (8, 11, 17, 21)?

This could live on the README in the GH repo. This would require an
update to the commons-build-plugin that generates it. But for a start
we can add a few sentences to the lang README under the building
section:

"The code is tested using the latest revision of the JDK for supported
LTS releases. Please ensure your build environment is up-to-date and
kindly report any build issues."

This should provide a first indicator to a user that the JDK must be
up-to-date and welcomes any feedback on building. This text may not be
suitable for all repos if they do not test across all LTS versions of
the JDK so may need some revision for the build-plugin.

Alex

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

Re: Apache Common Lang -- How do I compile or did I find a bug

[Alex Herbert]

I updated JDK 17.0.6 to 17.0.9 and lang now builds on my mac:

Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Java version: 17.0.9, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac"

So this is a JDK issue.

Alex

On Tue, 12 Dec 2023 at 11:51, Gary Gregory  wrote:
>
> See the GutHub builds as well. Make sure you have the latest Java version
> of the major release line you are using, which is not the case here, and
> might not matter.
>
> Note that some of the tests make allowances for bugs in the JDK date
> classes.
>
> Gary
>
> On Tue, Dec 12, 2023, 6:18 AM Alex Herbert  wrote:
>
> > I can confirm I see 3 test failures in the FastDateParser using:
> >
> > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> > Java version: 17.0.6, vendor: Eclipse Adoptium, runtime:
> > /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac"
> >
> > ---
> > [ERROR]
> >  
> > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147
> > java.text.ParseException: Unparseable date: Tempo universale
> > coordinato: with locale = it, zIndex = 3, tzDisplay = 'Tempo
> > universale coordinato', parser = 'FastDateParser[z, it, GMT]'
> > [ERROR]
> >  
> > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147
> > java.text.ParseException: Unparseable date: 세계 표준시: with locale = ko,
> > zIndex = 3, tzDisplay = '세계 표준시', parser = 'FastDateParser[z, ko,
> > GMT]'
> > [ERROR]
> >  
> > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_TimeZone:88->testTimeZoneStrategyPattern_TimeZone_getAvailableIDs:172
> > java.text.ParseException: Unparseable date: normaltid – Kanton: with
> > locale = nb, id = 'Pacific/Kanton', timeZone =
> >
> > sun.util.calendar.ZoneInfo[id="Pacific/Kanton",offset=4680,dstSavings=0,useDaylight=false,transitions=5,lastRule=null]
> > ...
> > ---
> >
> > Build is fine using on MacOS using:
> >
> > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> > Java version: 11.0.18, 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: "13.4.1", arch: "aarch64", family: "mac"
> >
> > Build is fine on Linux JDK 17 using:
> >
> > Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
> > Java version: 17.0.4.1, vendor: Oracle Corporation, runtime:
> > /usr/lib/jvm/jdk-17.0.4.1
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "linux", version: "5.4.0-167-generic", arch: "amd64", family:
> > "unix"
> >
> > The GH actions builds are green for MacOS latest on all JDKs. I see
> > you are using a similar OS version to my mac. So this may be a MacOS
> > Sonoma 14 vs MacOS Ventura 13 issue. It would be good if someone else
> > can replicate it on MacOS.
> >
> > Alex
> >
> > On Tue, 12 Dec 2023 at 08:52, Charles Stockman
> >  wrote:
> > >
> > > Hello and thanks for your help.
> > >
> > >
> > > How do I compile or did I find a bug ?
> > >
> > >
> > > I have been been attempting to build the latest version of Apache
> > >
> > > Common-Lang.
> > >
> > >
> > > The GitHub repository that I have used is
> > >
> > > https://github.com/apache/commons-lang.git
> > >
> > >
> > > I have the billed instructions mentioned in the following section :
> > >
> > > https://github.com/apache/commons-lang?tab=3Dreadme-ov-file#building
> > >
> > >
> > > The maven and java version that I have used is:
> > >
> > >
> > > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> > >
> > > Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec
> > >
> > > Java version: 17.0.7, vendor: Eclipse Adoptium, runtime: =
> >

Re: Apache Common Lang -- How do I compile or did I find a bug

[Alex Herbert]

I can confirm I see 3 test failures in the FastDateParser using:

Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Java version: 17.0.6, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac"

---
[ERROR]   
FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147
java.text.ParseException: Unparseable date: Tempo universale
coordinato: with locale = it, zIndex = 3, tzDisplay = 'Tempo
universale coordinato', parser = 'FastDateParser[z, it, GMT]'
[ERROR]   
FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147
java.text.ParseException: Unparseable date: 세계 표준시: with locale = ko,
zIndex = 3, tzDisplay = '세계 표준시', parser = 'FastDateParser[z, ko,
GMT]'
[ERROR]   
FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_TimeZone:88->testTimeZoneStrategyPattern_TimeZone_getAvailableIDs:172
java.text.ParseException: Unparseable date: normaltid – Kanton: with
locale = nb, id = 'Pacific/Kanton', timeZone =
sun.util.calendar.ZoneInfo[id="Pacific/Kanton",offset=4680,dstSavings=0,useDaylight=false,transitions=5,lastRule=null]
...
---

Build is fine using on MacOS using:

Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Java version: 11.0.18, 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: "13.4.1", arch: "aarch64", family: "mac"

Build is fine on Linux JDK 17 using:

Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
Java version: 17.0.4.1, vendor: Oracle Corporation, runtime:
/usr/lib/jvm/jdk-17.0.4.1
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-167-generic", arch: "amd64", family: "unix"

The GH actions builds are green for MacOS latest on all JDKs. I see
you are using a similar OS version to my mac. So this may be a MacOS
Sonoma 14 vs MacOS Ventura 13 issue. It would be good if someone else
can replicate it on MacOS.

Alex

On Tue, 12 Dec 2023 at 08:52, Charles Stockman
 wrote:
>
> Hello and thanks for your help.
>
>
> How do I compile or did I find a bug ?
>
>
> I have been been attempting to build the latest version of Apache
>
> Common-Lang.
>
>
> The GitHub repository that I have used is
>
> https://github.com/apache/commons-lang.git
>
>
> I have the billed instructions mentioned in the following section :
>
> https://github.com/apache/commons-lang?tab=3Dreadme-ov-file#building
>
>
> The maven and java version that I have used is:
>
>
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
>
> Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec
>
> Java version: 17.0.7, vendor: Eclipse Adoptium, runtime: =
>
> /Users/charlesstockman/.sdkman/candidates/java/17.0.7-tem
>
> Default locale: en_US, platform encoding: UTF-8
>
> OS name: "mac os x", version: "13.4", arch: "aarch64", family: =
>
> "mac"
>
>
> The steps were
>
>
> 1. git clone https://github.com/apache/commons-lang.git
>
> 1. cd commons-lang
>
> 2. mvn
>
>
> I have received the following error and attached the output
>
>
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.2.2:test (default-test) on 
> project commons-lang3: There are test failures.
>
> [ERROR]
>
> [ERROR] Please refer to 
> /Users/charlesstockman/otherGit/commons-lang/target/surefire-reports for the 
> individual test results.
>
> [ERROR] Please refer to dump files (if any exist) [date].dump, 
> [date]-jvmRun[N].dump and [date].dumpstream.
>
> [ERROR] -> [Help 1]
>
> [ERROR]
>
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
>
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>
> [ERROR]
>
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
>
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
>
> charlesstockman@Charless-Mini commons-lang %
>
>
>

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

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

[Alex Herbert]

On Sat, 18 Nov 2023 at 12:49, Gary Gregory  wrote:
>
> On Sat, Nov 18, 2023 at 3:36 AM Alex Herbert  wrote:
> >
> > Installed from the maven tag.
> >
> > Built lang and statistics using JDK 8 and 11:
> >
> > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> > Maven home: /Users/ah403/mvn/mvn
> > Java version: 1.8.0_362, vendor: Temurin, runtime:
> > /Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home/jre
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "mac os x", version: "13.4.1", arch: "x86_64", family: "mac"
> >
> > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> > Maven home: /Users/ah403/mvn/mvn
> > Java version: 11.0.18, 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: "13.4.1", arch: "aarch64", family: "mac"
> >
> > lang:
> > Fails on SpotBugs with 9 errors. Rerunning with -Dspotbugs.skip works.
> > I did not fix the source.
> >
> > statistics:
> > Fails on SpotBugs with 1 error in the inference module. Fixed in the source.
> > Fails on checkstyle under JDK 11 with errors due to private final
> > classes not declared as final. This is a strange one as IIRC other
> > tools state that the keyword is redundant. I have corrected in source
> > for now.
>
> The keyword cannot be redundant, otherwise, this would not work:
>
> public class Root {
>
> private static class SP1 {
> }
>
> private static class SP2 extends SP1 {
> }
>
> private class P1 {
> }
>
> private class P2 extends P1 {
> }
> }
>
> Or am I missing something?

The fact that it is private means that the final keyword to prevent
extension by others is mute. It does of course prevent extension by
yourself. But since you control the source then you can add or drop it
as desired. It makes no difference to downstream consumers of the
class.

Alex

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

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

[Alex Herbert]

Installed from the maven tag.

Built lang and statistics using JDK 8 and 11:

Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Maven home: /Users/ah403/mvn/mvn
Java version: 1.8.0_362, vendor: Temurin, runtime:
/Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.4.1", arch: "x86_64", family: "mac"

Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Maven home: /Users/ah403/mvn/mvn
Java version: 11.0.18, 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: "13.4.1", arch: "aarch64", family: "mac"

lang:
Fails on SpotBugs with 9 errors. Rerunning with -Dspotbugs.skip works.
I did not fix the source.

statistics:
Fails on SpotBugs with 1 error in the inference module. Fixed in the source.
Fails on checkstyle under JDK 11 with errors due to private final
classes not declared as final. This is a strange one as IIRC other
tools state that the keyword is redundant. I have corrected in source
for now.

+1

Alex

On Sat, 18 Nov 2023 at 03:42, Gary Gregory  wrote:
>
> I should have said this is a LAZY VOTE.
>
> Gary
>
> On Fri, Nov 17, 2023, 9:22 PM Gary Gregory  wrote:
>
> > We have made some enhancements since Apache Commons Parent 64 was
> > released, so I would like to release Apache Commons Parent 65.
> >
> > Apache Commons Parent 65 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/parent/65-RC1 (svn
> > revision 65392)
> >
> > The Git tag commons-parent-65-RC1 commit for this RC is
> > d6b68690bead91ce5ac31347df2d56f48aa97489 which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=d6b68690bead91ce5ac31347df2d56f48aa97489
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> > --branch 
> > commons-parent-65-RC1 commons-parent-65-RC1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1673/org/apache/commons/commons-parent/65/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Fri Nov 17 21:03:32 EST 2023
> >
> > commons-parent-65-bom.json=b2f18d4e4da464cb3b677d6f474da13b3c728cbbdeed82dda6a0d21c903352da4220635557e6d08d4240b0cb4f67268759bcddc037cc80f9976dea69f072f09e
> >
> > commons-parent-65-bom.xml=5b59a00e18ed0a71dbbc8b47eaf9f84f35ac066ea94ee47ff1fc0580c8dd602b74cd122b909e97e5359e74bc6b164025da9858d53ed14e382a97edde7ac17a14
> >
> > commons-parent-65-site.xml=5f045989b2c281c567467548678fe8685efabf5c13104299eea87b6ab6b6a75c9e98b590d7b288b8ec3a06934061709d0851a6dd9d9b45100ee2950908ec2d6c
> >
> > commons-parent-65-src.tar.gz=afc826950640e31bf61a16d61a953ddbf479a5ed8018a1051246802364c1eeef9aeb523233086837963db236ccc812b0007a381ef1394362a54c92031c9ce82e
> >
> > commons-parent-65-src.zip=8ae1a2a7e97d39f231aac0e20cc16724d5aecee62256c472496058d1fcd11e07f3c92d1515d5a42f41a0ce5d8282db734b6c21a9dd996861b5b7336f68fcdce6
> >
> > org.apache.commons_commons-parent-65.spdx.json=a9814adf2044737f18936037ef5427e7b3d2ce01d5e1f5516d4efcd411f7b532f97f5225da640667dc4fcf286bda1052f274875653698630fcde6458d74faa68
> >
> > I have tested this with
> >
> > mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> > deploy
> >
> > Using:
> >
> > Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
> > Maven home: /usr/local/Cellar/maven/3.9.5/libexec
> > Java version: 21.0.1, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk/21.0.1/libexec/openjdk.jdk/Contents/Home
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "14.1.1", arch: "x86_64", family: "mac"
> > Darwin gdg-mac-mini.local 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct
> >  9 21:27:27 PDT 2023; root:xnu-10002.41.9~6/RELEASE_X86_64 x86_64
> >
> > Details of changes since 64 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/parent/65-RC1/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/parent/65-RC1/site/changes-report.html
> >
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/parent/65-RC1/site/index.html
> > (note some *relative* links are broken and the 65 directories are
> > not yet created - these will be OK once the site is deployed.)
> >
> > RAT Report:
> >
> > https://dist.apache.org/repos/dist/dev/commons/parent/65-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,
> > R

Re: (commons-rng) branch master updated: Normalize spelling to US English

[Alex Herbert]

Note:

On Tue, 31 Oct 2023 at 10:21,  wrote:
> Normalize spelling to US English

>  .../commons/rng/examples/stress/RNGUtils.java  | 30 
> ++

> +/** Message for an unrecognized source64 mode. */
> +private static final String UNRECOGNISED_SOURCE_64_MODE = "Unrecognized 
> source64 mode: ";

Change the constant name too.

> +/** Message for an unrecognized native output type. */
> +private static final String UNRECOGNISED_NATIVE_TYPE = "Unrecognized 
> native output type: ";

Change the constant name too.

Alex

-
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

[Alex Herbert]

I opened a PR after changing the expected failure probability to 1e-5.

I had an old version of the GH build file when I estimated it used 4
runs. The latest CI runs 4 JDKs on 3 platforms plus CodeQL and
coverage. So this is 14 runs. We should see failures with a
probability of:

(1 - (1 - 1e-5)**14) = 0.0001399, or approximately 1 in 7143.

Compare that to previously:

(1 - (1 - 1e-3)**14) = 0.01391, or approximately 1 in 71.89.

If this is still a problem moving forward then we can replace with a
fixed random number generator calling the underlying method and test
coverage of the original method by other means.

Alex

On Fri, 20 Oct 2023 at 20:16, Gary D. Gregory  wrote:
>
> 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
>

-
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

[Alex Herbert]

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

Re: [lang] RandomStringUtilsTest.testRandomStringUtilsHomog fails a lot

[Alex Herbert]

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

On Fri, 20 Oct 2023 at 18:44, Elliotte Rusty Harold  wrote:
>
> It's possible the chi square test is miscalculated. Perhaps some stats
> expert can check that. It's also possible the chi square test isn't
> the right one to use here. Again, consult a stats expert.
>
> It's also very possible that the randomness is not nearly as random as
> it's supposed to be. That's incredibly common, and that might be
> noticeable given the very short three-letter character set [a, b, c]
> being picked from.
>
> On Fri, Oct 20, 2023 at 1:31 PM Gary D. Gregory  wrote:
> >
> > 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
> >
>
>
> --
> 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: [ALL] Java CI badge does not agree with workflow status

[Alex Herbert]

Navigating to the Java CI workflow you can generate a badge using the
... menu in the top right next to the search filter. This creates a
badge with a different URL to that currently in use:

Current:
[![GitHub Actions
Status](https://github.com/apache/commons-build-plugin/workflows/Java%20CI/badge.svg)](https://github.com/apache/commons-build-plugin/actions)

Generated:
[![Java 
CI](https://github.com/apache/commons-build-plugin/actions/workflows/maven.yml/badge.svg)](https://github.com/apache/commons-build-plugin/actions/workflows/maven.yml)

Using the badge URL shows a green badge.

Another working version from Statistics is the same E.g.:

https://github.com/apache/commons-statistics/actions/workflows/maven.yml/badge.svg

So try a badge update with a different URL.

Alex



On Fri, 20 Oct 2023 at 16:03, sebb  wrote:
>
> The build-plugin readme shows a failing Java CI build:
>
> https://github.com/apache/commons-build-plugin
>
> However the build has been working for ages:
>
> https://github.com/apache/commons-build-plugin/actions/workflows/maven.yml
>
> Any idea how this can be fixed?
>
> Not much point having the badge if it is stale.
>
> Sebb
>
> -
> 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: [Text] Java 21 failure with a double

[Alex Herbert]

I've implemented a fix for this in PR 467 [1]. Builds now pass on JDK 21.

This does not change the DoubleFormat class. It adds javadoc to state
that the formatting is dependent on Double.toString.

The tests have been updated to use a different range for the random
doubles so the tests across formats should be testing roughly the same
precision. They should not test the full precision output (i.e. 17
digits).

Note that this change identified another mismatch between the
reference DecimalFormat and the DoubleFormat when a zero trails the
decimal point. The DecimalFormat class can omit this trailing zero and
the decimal point:

new DecimalFormat("##0.0##E0").format(1.129e-4) => 113E-6(not 113.0E-6)

The inelegant solution I used was to remove .0 from the DecimalFormat
output and recheck the string is a match. This allows the above case
to pass. There are no other cases in the 1000 random numbers that hit
this mismatch case.

A new test has been added for full precision output. The test requires
that the output format can be parsed back to the same number, i.e. no
loss of precision occurs when formatting. This seemed simpler than
writing custom code to check against the digits output from
Double.toString to ensure all digits are present.

Alex

[1] https://github.com/apache/commons-text/pull/467

On Mon, 16 Oct 2023 at 18:37, Alex Herbert  wrote:
>
> TLDR; The Double.toString(double) value is different for
> -9.354004711977437E17 on JDK 21 and earlier JDKs:
>
> JDK 21: -9.354004711977437E17
> JDK 17: -9.3540047119774374E17
>
> The DoubleFormat class is built upon Double.toString. So the test
> fails due to this change.
>
> ---
>
> More details:
>
> On JDK 21 Double.toString is dropping the last digit (a 4) as it is
> not required to uniquely represent the double from the next double up
> or down. Note the javadoc for toString states: "This decimal is
> (almost always) the shortest one that rounds to m according to the
> round to nearest rounding policy of IEEE 754 floating-point
> arithmetic." So this is not the closest decimal representation of the
> double, just the closest required for rounding to the double.
>
> I do not think this is a bug. But we should document that the
> DoubleFormat class is built upon the Double.toString representation of
> a double. This string may not be the closest decimal representation of
> the double. Thus final digit errors can be observed when using the
> entire character output of Double.toString compared to other
> formatting classes such as java.lang.DecimalFormat or the numerical
> string representation provided by java.lang.BigDecimal (see examples
> below).
>
> Q. How to fix the test?
>
> The DoubleFormatTest is using 1000 random double values with a base-2
> exponent of -100 to 100. Then testing against a plain text format of
> 0.00##. The exponent of 9.35e17 is 59. It is so large there are no
> digits after the decimal point. So the test is checking if
> DoubleFormat is accurate to 17 decimal digits of precision, which it
> is not in this case. The other tests using the random numbers test the
> formats:
>
> #,##0.0##
> 0.0##E0
> ##0.0##E0
>
> So the scientific and engineering tests are only checking 4 and 6
> decimal digits. But the plain formats are checking up to 17 digits due
> to the large exponent of the random numbers. This does not seem very
> fair.
>
> Fix 1: A simple fix would be to reduce the exponent range for random
> numbers so that the plain numbers should always have at least 4 digits
> after the decimal point.
>
> However, changing the test like this would reduce its power. It would
> not have alerted us to this failure.
>
> Fix 2: An alternative would be to change the test assertion to perform
> the current check, and if it fails perform a test that all digits from
> Double.toString are present in the formatted string in the same order
> (i.e. the class has used the entire output from Double.toString and so
> is at its limit). This is non-trivial as the double value is tested in
> all the installed locales which may change the digits and other
> formatting characters. The assertion would have to create a reverse
> parsing method based on the locale.
>
> Note: I did try using the DecimalFormat used to specify formatting the
> expected string to parse the string with DecimalFormat.parse. It
> worked on the original root locale but it failed on locale "he"; this
> may be another bug in DoubleFormat since the locale can parse its own
> output:
>
> jshell> var df = new java.text.DecimalFormat("0.0##",
> java.text.DecimalFormatSymbols.getInstance(Locale.forLanguageTag("he")))
> jshell> x
> x ==> -9.3540047119774374E17
> jshell> df.parse(df.f

Re: [Text] Java 21 failure with a double

[Alex Herbert]

TLDR; The Double.toString(double) value is different for
-9.354004711977437E17 on JDK 21 and earlier JDKs:

JDK 21: -9.354004711977437E17
JDK 17: -9.3540047119774374E17

The DoubleFormat class is built upon Double.toString. So the test
fails due to this change.

---

More details:

On JDK 21 Double.toString is dropping the last digit (a 4) as it is
not required to uniquely represent the double from the next double up
or down. Note the javadoc for toString states: "This decimal is
(almost always) the shortest one that rounds to m according to the
round to nearest rounding policy of IEEE 754 floating-point
arithmetic." So this is not the closest decimal representation of the
double, just the closest required for rounding to the double.

I do not think this is a bug. But we should document that the
DoubleFormat class is built upon the Double.toString representation of
a double. This string may not be the closest decimal representation of
the double. Thus final digit errors can be observed when using the
entire character output of Double.toString compared to other
formatting classes such as java.lang.DecimalFormat or the numerical
string representation provided by java.lang.BigDecimal (see examples
below).

Q. How to fix the test?

The DoubleFormatTest is using 1000 random double values with a base-2
exponent of -100 to 100. Then testing against a plain text format of
0.00##. The exponent of 9.35e17 is 59. It is so large there are no
digits after the decimal point. So the test is checking if
DoubleFormat is accurate to 17 decimal digits of precision, which it
is not in this case. The other tests using the random numbers test the
formats:

#,##0.0##
0.0##E0
##0.0##E0

So the scientific and engineering tests are only checking 4 and 6
decimal digits. But the plain formats are checking up to 17 digits due
to the large exponent of the random numbers. This does not seem very
fair.

Fix 1: A simple fix would be to reduce the exponent range for random
numbers so that the plain numbers should always have at least 4 digits
after the decimal point.

However, changing the test like this would reduce its power. It would
not have alerted us to this failure.

Fix 2: An alternative would be to change the test assertion to perform
the current check, and if it fails perform a test that all digits from
Double.toString are present in the formatted string in the same order
(i.e. the class has used the entire output from Double.toString and so
is at its limit). This is non-trivial as the double value is tested in
all the installed locales which may change the digits and other
formatting characters. The assertion would have to create a reverse
parsing method based on the locale.

Note: I did try using the DecimalFormat used to specify formatting the
expected string to parse the string with DecimalFormat.parse. It
worked on the original root locale but it failed on locale "he"; this
may be another bug in DoubleFormat since the locale can parse its own
output:

jshell> var df = new java.text.DecimalFormat("0.0##",
java.text.DecimalFormatSymbols.getInstance(Locale.forLanguageTag("he")))
jshell> x
x ==> -9.3540047119774374E17
jshell> df.parse(df.format(x)).doubleValue()
$32 ==> -9.3540047119774374E17

Fix 3: Implement fix 1, plus add a test for full length precision
using only the root locale. This can quickly test the output is at the
limit by checking the string creates the original input double using
Double.parseDouble, i.e. the DoubleFormat has captured the entire
information required to uniquely recreate the original double.

Alex

---

Here is the failure:

[ERROR] Failures:
[ERROR]   
DoubleFormatTest.testPlain_localeFormatComparison:491->checkLocalizedFormats:127->checkLocalizedFormat:121->assertLocalized
FormatsAreEqual:40 Unexpected output for locale [und] and double value
-9.354004711977437E17 ==> expected: <-935400471197743740.0> bu
t was: <-935400471197743700.0>

The Double.toString value is the minimum string required to uniquely
identify the double value; this is the string required to round trip
the number to a string and back via Double.parseDouble(String).
However, it may not be the closest decimal representation of the
value.

In the failed test the double value is -9.354004711977437E17 which can
be interpreted differently. I obtained the value that failed using
Double.doubleToLongBits. This has different representations depending
on how it is output:

jshell
|  Welcome to JShell -- Version 17.0.6
|  For an introduction type: /help intro

jshell> double x = Double.longBitsToDouble(-4347673023486037259L)
x ==> -9.3540047119774374E17

jshell> new BigDecimal(x)
$2 ==> -935400471197743744

// Using the DecimalFormat from the failing test:
jshell> new java.text.DecimalFormat("0.0##",
java.text.DecimalFormatSymbols.getInstance(Locale.ROOT)).format(x)
$3 ==> "-935400471197743740.0"

jshell> Math.nextUp(x)
$4 ==> -9.3540047119774362E17

jshell> Math.nextDown(x)
$5 ==> -9.3540047119774387E17


Note the difference for JDK 21:

Re: [ALL] Standardise Maven defaultGoal in components?

[Alex Herbert]

On Sun, 8 Oct 2023 at 22:53, sebb  wrote:
>
> > > On Oct 8, 2023, at 7:11 AM, sebb  wrote:
> > >
> > > There are currently lots of variations of the defaultGoal in different
> > > components.
> > >
> > > It may be sensible to establish a standard setting which components
> > > should adopt (unless there is a good reason to do otherwise).
> > >
> > > If so, what should that be, and where does it get documented?
> > >
> > > Personally, I don't think install should ever be a default goal as it
> > > changes the environment outside the component.
> > >
> > > Main goals seen:
> > > clean
> > > install
> > > package
> > > site
> > > test
> > > verify
> > >
> > > Other goals seen:
> > > apache-rat:check
> > > checkstyle:check
> > > clirr:check
> > > findbugs:check
> > > japicmp:cmp
> > > javadoc:javadoc
> > > pmd:check
> > > pmd:cpd-check
> > > spotbugs:check

Note that some poms will be configured to use executions to bind goals
to lifecycle phases. So the default goal may only be 'clean verify'
but many plugins will be executed. For example the commons-parent pom
runs apache-rat-plugin in the validate phase making this explicit goal
redundant in all our projects; the multi-module RNG component uses
'clean verify javadoc:javadoc' but executes PMD, SpotBugs and
Checkstyle in executions bound to the verify phase. There are also
some plugins that have executions bound to verify but activated by the
presence of a file, for example RevAPI/JApiCmp for modules building a
jar; these can be disabled by lack of a file for modules with a
non-jar packaging.

I think making the default goal run verify is appropriate as this is
where many validation plugins are conventionally configured to run. It
allows a quicker build with 'mvn test' and a full check with 'mvn'.

Alex

-
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 63 based on RC2

[Alex Herbert]

Can you provide the usage for the new  property?
This is listed in the release notes as a new feature thanks to
dependabot. But the commit was a single line added by Gary. I do not
think it is attributed to dependabot. It is added under the release
management section for properties for the Commons Release plugin but I
cannot find 'commons.conf.dir' referenced in the current release
plugin code.

Alex

On Mon, 2 Oct 2023 at 13:28, Gary Gregory  wrote:
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons Parent 62 was released, so I would like to release Apache
> Commons Parent 63.
>
> Apache Commons Parent 63 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/63-RC2
> (svn revision 64292)
>
> The Git tag commons-parent-63-RC2 commit for this RC is
> cf512e1352e886a50c1f292420dbc052bdedbf39 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=cf512e1352e886a50c1f292420dbc052bdedbf39
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-63-RC2 commons-parent-63-RC2
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1662/org/apache/commons/commons-parent/63/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Mon Oct 02 07:53:04 EDT 2023
> commons-parent-63-src.tar.gz=415919a83c9a84101c586e36da25aeacad9126119e5f3bee1de8db8e4dbda46c5b0a28a0c440ea64254533f31d31be5e2904838e1dd72d456e7befde7a6b2f77
> org.apache.commons_commons-parent-63.spdx.json=51ef87a005d61ad1aa1318770ad79f4decbe717d7a570266c3ad24223fe5f7e7fcaf0ef162a5e6dc232ba6f79799f484ce68345a8bf164bf52f6992bf6d5cc7c
> commons-parent-63-site.xml=5f045989b2c281c567467548678fe8685efabf5c13104299eea87b6ab6b6a75c9e98b590d7b288b8ec3a06934061709d0851a6dd9d9b45100ee2950908ec2d6c
> commons-parent-63-src.zip=3674e727c8a770117d40d21812d581774446d9144a9625d3b45535231ccc9ad7e923397d1e9df16133888fbcc8745c573639f89523ba3dd360d459d08069eea1
> commons-parent-63-bom.json=d08fbea2168dcd027d6c2928c3604f22b081d4d88fd480f1f2b282c3ac32a15f312e47e72ad0d0f525680e931d311fe51472e9b6450e2bde5ee1a3f4632aaad2
> commons-parent-63-bom.xml=36d3cb1aed436d44fbb97ef16e1e603196598dea68cc113ebfe630c7044a214132c6e7444f32f4e90ba8bf5d47f357d3426afa37b4ea6a8e735ddd666e8d0744
>
> I have tested this with:
>
> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
>
> using:
>
> Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: /usr/local/Cellar/maven/3.9.4/libexec
> Java version: 17.0.8.1, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@17/17.0.8.1/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.0", arch: "x86_64", family: "mac"
>
> Darwin  23.0.0 Darwin Kernel Version 23.0.0: Fri Sep 15 14:42:42
> PDT 2023; root:xnu-10002.1.13~1/RELEASE_X86_64 x86_64
>
> Details of changes since 62 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/63-RC2/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/63-RC2/site/changes-report.html
>
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/63-RC2/site/index.html
> (note some *relative* links are broken and the 63 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/63-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,
>
> 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-63-RC2 commons-parent-63-RC2
> cd commons-parent-63-RC2
>
> 1b) Download and unpack the source archive from:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/63-RC2/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 J

Re: [BUILD-PLUGIN] Drop component list from README template?

[Alex Herbert]

On Mon, 2 Oct 2023 at 10:05, sebb  wrote:
>
> The Build Plugin currently includes a list of components in the README 
> template.
>
> This duplicates information provided elsewhere, and gets out of date.
>
> Since this info is in every GH repo, any changes also need to be
> applied to every one of them, to ensure they are up to date.
>
> This is an unnecessary maintenance burden.
>
> I think this local list should be dropped, and replaced with a link to
> the main website.

+1

Alex

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

[statistics] descriptive module

[Alex Herbert]

I have been looking at continuing the work on the descriptive module
to add the remaining stats found in Commons Math. Before adding more
classes I would like to address the current implementation pattern.

The statistics in the descriptive module are currently abstract
classes with a concrete inner class that is prefixed Storeless.

This pattern would make sense if there was the intention to provide
stored implementations. Currently I do not think this would be the
best solution. For example it would make sense to separate the storage
of a variable size stream of double values, from the computation of a
statistic. That is, a resizable backing array storage is out of scope
for this module.

I propose to simplify the current implementations to final classes
that implement the current Storeless functionality. Any future change
to stored, immutable, or other implementations can be provided by
changing the final class back to abstract with different
implementations.

Alex

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

Re: [MATH] Inconsistent artifactId for parent pom

[Alex Herbert]

On Wed, 20 Sept 2023 at 14:24, sebb  wrote:
>
> The artifactId for the parent pom is
>
> commons-math-parent
>
> whereas all the child poms have the prefix
>
> commons-math4-
>
> Seems to me this ought to be fixed before the first GA release
> (current is 4.0-beta2)

The current parent was probably copied from one of the derived
multi-module projects (e.g. RNG/Numbers) which are still on major
version 1. Feel free to fix it in git master.

Alex

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

Re: [DRAFT][REPORT] September 2023

[Alex Herbert]

You could add that we had a successful participant in Google Summer of
Code 2023 working on the statistics sub-project. This may apply to the
community section.

Alex

On Wed, 13 Sept 2023 at 02:59, Gary Gregory  wrote:
>
> Here is the report I plan on filing, probably in the AM (EST):
>
> ## 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 (16 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:
> Our recent releases are:
> - COMPRESS-1.24.0 was released on 2023-09-08.
> - PARENT-62 was released on 2023-09-05.
> - DBCP-2.10.0 was released on 2023-09-03.
> - PARENT-61 was released on 2023-08-29.
> - PARENT-60 was released on 2023-08-23.
> - DBUTILS-1.8.0 was released on 2023-08-08.
> - LANG-3.13.0 was released on 2023-07-28.
> - PARENT-59 was released on 2023-07-26.
> - FILEUPLOAD-2.0.0-M1 was released on 2023-07-19.
> - BUILD-PLUGIN-1.13 was released on 2023-06-28.
> - RELEASE-PLUGIN-1.8.1 was released on 2023-06-28.
> - CODEC-1.16.0 was released on 2023-06-21.
>
> ## Community Health:
> We have had much more activity on the mailing lists, Jira, and GitHub. We are
> also reviewing security reports as they come in and have been working through
> that backlog.
>
> 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] AbstractLinkedList is source incompatible with JDK 21

[Alex Herbert]

On Fri, 8 Sept 2023 at 13:46, Alex Herbert  wrote:



> The problem then becomes how to support AbstractLinkedList and
> CursorableLinkedList. Currently collections4 will not be source
> compatible with JDK 21. Any downstream project that extends these
> classes will not be source compatible with JDK 21.

Extra:

Note that this incompatibility is true when targeting Java 21 as the release.

If compiling for an earlier Java release then this is possible using
JDK 21 via the javac --release flag.

Collections is a very long way from targeting Java 21 (it currently
targets Java 8). A third option would be:

3. Simply mark the methods as deprecated

This acknowledges the issue but does nothing to fix it. The fix can be
done with the bump to collections 5 when that happens. This will not
support cutting edge users who are targeting Java 21. This would be
expected to be a subset of the unknown number of users for these
classes. A workaround would be the user uses a local copy of the class
to allow source compilation (license permitting).

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

[collections] AbstractLinkedList is source incompatible with JDK 21

[Alex Herbert]

JDK 21 has added these methods to java.util.List:

default public void addFirst(E o)
default public void addLast(E o)

These are source incompatible with Commons Collections AbstractLinkedList:

public boolean addFirst(E o)
public boolean addLast(E o)

This affects AbstractLinkedList and any list that extends it
(CursorableLinkedList and NodeCachingLinkedList).

This issue was identified by Julian Reschke (see [1, 2]) due to use of
code that extends AbstractLinkedList in Apache Jackrabbit.

The source incompatibility means that collections, or any project that
extends these List classes, cannot be compiled with Java 21. Class
files compiled with Java < 21 are runtime compatible with Java 21.

A performance test (on one machine) shows that NodeCachingLinkedList
may no longer offer any performance gain over the base implementation.
The NodeCachingLinkedList differs in that it reuses nodes rather than
allowing garbage collection. Subject to further performance testing,
this implementation can be deprecated.

CursorableLinkedList provides functionality not in the JDK LinkedList.
This is to allow concurrent changes to the list with list methods and
iterator methods, or multiple iterators, for the lifetime of all
iterators. In contrast JDK LinkedList only allows modification to the
list via the (single) iterator during the lifetime of the iterator.

The problem then becomes how to support AbstractLinkedList and
CursorableLinkedList. Currently collections4 will not be source
compatible with JDK 21. Any downstream project that extends these
classes will not be source compatible with JDK 21.

Possible solutions:

1. Duplicate AbstractLinkedList (and possibly CursorableLinkedList) in
collections4 and update the methods signatures to be compatible in the
duplicate.

This solution allows collections4 to be compiled with JDK 8, 11, 17.
It cannot be compiled with 21. Any downstream project can extend the
duplicate class and be compiled under Java 21 (assuming all references
to incompatible classes are removed).

2. Bump collections major version to 5 and fix the incompatibility.

Note that collections 4.4 was released in Jul 2019. This option could
perform one last release of collections 4 to release all fixes and
changes, then proceed to collections 5 for the development branch.

I am unfamiliar with the entire collections codebase and the clean-up
work required for a major revision bump. Note the new bloomfilter
package is as yet unreleased. So choosing this option provides the
ability to release a 5-beta to receive community feedback on the
bloomfilter API before an official release.

Any other options are welcomed for discussion.

Alex

[1] https://lists.apache.org/thread/lnrzdv348q8g64dlno6xq84wb49vbc2c
[2] https://issues.apache.org/jira/browse/COLLECTIONS-842

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

Re: [commons-math] function or Number class to count/track number of significant figures

[Alex Herbert]

On Wed, 9 Aug 2023 at 17:13, Daniel Watson  wrote:

> BigSigFig result = new BigSigFig("1.1").multiply(new BigSigFig("2"))

Multiply is easy as you take the minimum significant figures. What
about addition?

12345 + 0.0001

Here the significant figures should remain at 5.

And for this:

12345 + 10.0
12345 + 10
12345 + 1
12345 + 1.0
12345 + 1.00

You have to track the overlap of significant digits somehow.

Alex

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

Re: [commons-math] function or Number class to count/track number of significant figures

[Alex Herbert]

On Wed, 9 Aug 2023 at 15:43, Daniel Watson  wrote:
>
> Hope that answers more questions than it creates!

It does not address the issue of the last significant zero, e.g:

1 (4 sf)
1 (3 sf)
1 (2 sf)

One way to solve this with standard parsing would be to use scientific notation:

1.000e4
1.00e4
1.0e4

Note that for the example of inch to cm conversions the value 2.54
cm/inch is exact. This leads to the issue that there should be a way
to exclude some input from limiting the detection of the lowest
significant figure (i.e. mark numbers as exact). This puts some
responsibility on the provider of the data to follow a format; and
some on the parser to know what fields to analyse.

Alex

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

Re: [commons-math] function or Number class to count/track number of significant figures

[Alex Herbert]

Hi,

On Wed, 9 Aug 2023 at 12:27, Daniel Watson  wrote:

> This feature is necessary when working with scientific/clinical data which
> was reported with significant figures in mind, and for which calculation
> results must respect the sigfig count. As far as I could tell there is no
> Number implementation which correctly respects this. e.g.
>
> "11000" has 2 significant figures,
> "11000." has 5
> ".11000" has 5
> "11000.0" has 6

This functionality is not in Commons AFAIK. Is the counting to accept
a String input?

Q. What is the use case that you would read data in text format and
have to compute the significant figures? Or are you reading data in
numeric format and computing the decimal significant figures of the
base-2 data representation? Note: Differences between base-10 and
base-2 representations can lead to an implementation that satisfies
one use case and not others due to rounding conversions (see
NUMBERS-199 [1]). I would advise against this and only support text
input when referring to decimal significant figures.

I presume you have input data of unknown precision, are computing
something with it, then outputting a result and wish to use the
minimum significant figures from the input data. If the output
significant figures are critical then this is a case where I would
expect the reported significant figures to be manually verified; thus
automation only partly increases efficiency by providing a first pass.

Note: I do not think there is an easy way to handle trailing zeros
when not all the zeros are significant [1]. This is in part due to the
different formats used for this such as an overline/underline on the
last significant digit. I do not think we wish to support parsing of
non-ascii characters and multiple options to identify significant
zeros. Thoughts on this?

Secondly, you are reliant on the text input being correctly formatted.
For example if I include the number 1, it would have to be represented
as e.g. 1.000 to not limit the significant figures of the rest of the
input data.

Thirdly, if accepting string input then you have the issue of first
identifying if the string is a number. This is non-trivial. For
example there is a function to do it in o.a.c.lang3.math in
NumberUtils.isCreatable.

Finding a home in commons will elicit different opinions from the
various contributors. The math and numbers projects are more related
to numeric computations. They output results in a canonical format,
typically the JDK toString representation of the number(s).
Conversions to different formats are not in scope, and parsing is
typically from the canonical format using JDK parse methods. There is
a o.a.c.text.numbers package in the text component that currently has
formatting for floating-point numbers to various text representations.
But parsing of Strings is not supported there. And lang has the
NumberUtils.

As for a class that tracks significant figures through a computation,
that will require some consideration. Do we create the class to wrap
Number and track significant digits of a configurable base. This would
allow BigDecimal with base 10, or int and double with base 2. Since
Number does not specify arithmetic then this has to be captured
somehow. It may be able to use the Numbers implementation of Field [3]
in o.a.c.numbers.field. Or simplify to only using a BigDecimal
wrapper.

In summary this may be simpler with an ideal use case. For example the
input is text, it must be parable to a BigDecimal and the number of
significant figures is identified using the text input. Support of
significant zeros is limited to the full length of the trailing zeros,
or the first zero if no decimal point is provided. This could be
handled with a parse method that returns both the BigDecimal and the
significant figures.

Alex

[1] https://issues.apache.org/jira/browse/NUMBERS-199
[2] 
https://en.wikipedia.org/wiki/Significant_figures#Ways_to_denote_significant_figures_in_an_integer_with_trailing_zeros
[3] http://mathworld.wolfram.com/Field.html

-
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 59 based on RC1

[Alex Herbert]

I installed it locally from the git tag. I build the following
projects with their default mvn goal using:

Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
Maven home: /usr/local/apache-maven-3
Java version: 1.8.0_362, vendor: Private Build, runtime:
/usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-153-generic", arch: "amd64", family: "unix"

RNG
Numbers
Statistics
Lang
Text

No issues found except some javadoc warnings in Text when linking to
private members. I have fixed this in master.

+1

On Sat, 22 Jul 2023 at 21:34, Gary Gregory  wrote:
>
> We have updated the Apache Commons POM since Apache Commons Parent 58
> was released, so I would like to release Apache Commons Parent 59.
>
> Apache Commons Parent 59 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/59-RC1
> (svn revision 63135)
>
> The Git tag commons-parent-59-RC1 commit for this RC is
> 86b1b6f9575219f9009cdc89ddf3f1450e9f8982 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=86b1b6f9575219f9009cdc89ddf3f1450e9f8982
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-59-RC1 commons-parent-59-RC1
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1646/org/apache/commons/commons-parent/59/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sat Jul 22 16:24:00 EDT 2023
> commons-parent-59-bom.json=094208bc437b500fd33853d186fda8728257519ab0fe59dbfcb1d0eb96a822a9f0fbbcb103d29539dada9b2ddd7ef530197bfd2558d112e006e327931ceb35da
> commons-parent-59-bom.xml=1a7b5b636ceb6c2b1cd23a31d2b4c19f35fe7c037502e439132d86e85b367fbc173c17a7a60449a6b9073194b2c2987762a4cc54e68211a55015745bdb1a5c88
> commons-parent-59-site.xml=c6aea4f2c03920366bee23b08b046dacc09710e92c78ccd83f47cd92f89bc53abc3b8bbc7f44017ee94a2cb022ce763fe3f7d8c9aa42d571350269ba6568ca07
> commons-parent-59-src.tar.gz=71acd5fb605fa2eaede743319a7ad0aed57bfa438152a84dd284bf075807d91a4db52251c718c0d3428a80f43d0022f678ca74a784a80f14f063d1973e6ade7b
> commons-parent-59-src.zip=080f4deab4863f64f5324e4f43e25a1b7dfef96962dd4afc3227356155aa1aa7fdc314c8499777058789b0748f332b8ad91ba3d5f2b67457a494e9380204d758
> org.apache.commons_commons-parent-59.spdx.json=b9614d9c1143eb8c7f5d79c3ec19f701ba395fe903e3f18280b245e35296e0a9f4ad53eeea85e6b59c0751c85e1a6db71cf5fd5a58b0c0e6ee9da09737626657
>
> I have tested this with
>
> mvn -V -Ddoclint=none -Prelease -Ptest-deploy clean package site deploy
>
> using:
>
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f)
> Maven home: /usr/local/Cellar/maven/3.9.3/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.4.1", arch: "x86_64", family: "mac"
> Darwin  22.5.0 Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:22
> PDT 2023; root:xnu-8796.121.3~7/RELEASE_X86_64 x86_64
>
> Details of changes since 58 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/59-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/59-RC1/site/changes-report.html
>
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/59-RC1/site/index.html
> (note some *relative* links are broken and the 59 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/59-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 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-59-RC1 commons-parent-59-RC1
> cd commons-parent-59-RC1
>
> 1b) Download and unpack the source archive from:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/59-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 us

Re: [Pool] Toward version 2.12.0 and 3.0

[Alex Herbert]

On Wed, 19 Jul 2023 at 19:38, Gary Gregory  wrote:
>
> OK, that sounds good.
>
> Gary
>
> On Tue, Jul 18, 2023 at 5:50 PM Phil Steitz  wrote:
> >
> > I would say 17 for 3.0.
> >
> > Phil

Are there aspects of Pool that require moving away from JDK 8? Such a
move would restrict downstream consumers of the library.

Alex

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

Re: Move math algorithms from all projects to math libraries

[Alex Herbert]

On Tue, 18 Jul 2023 at 09:43, Gilles Sadowski  wrote:
>
> Hello.
>
> Le mar. 18 juil. 2023 à 02:48, Dimitrios Efthymiou
>  a écrit :
> >
> > Thanks Gilles. I checked NUMBERS-193 and i have an implementation of DD and
> > i will put it in *.ext package (TBD) along with some tests. Do i have to
> > look at Dfd.java or something, because these dfd classes in math legacy
> > core have lots of hard-coded decimals in there.
>
> Yes, we need to sort out what to with with the "Dfp" classes: I don't
> know how useful they will be once the DD implementation is available.
> We'll perhaps need benchmarks to assess speed vs precision among
> all extended precision implementations:
>  * DD in [Numbers],
>  * Dfp in [Math]
>  * BigDecimal in the JDK
>
> If "Dfp" is somehow (TBD) useful, it should be moved to a module of
> its own, perhaps in [Numbers].

Note: Dfp is not in the same category as a double-double number as it
is an "unlimited" precision number. It has a configurable decimal
precision and a larger exponent range than a double. It also has
support for various elementary functions (exp, exp1p, log, log1p, sin,
cos, etc). As such it is very valuable to fill a void where BigDecimal
cannot be used since that only supports pow and, from JDK 9+, sqrt. I
expect the speed would be comparable to BigDecimal and so a JMH test
would be useful.

Moving it out of math to a new module in numbers would be a chance to
revisit the code. But it is a large and complex class. I would not
change its implementation without a very thorough set of tests against
other comparable unlimited precision number implementations in other
libraries (Python mpmath; Maxima; Matlab vpa; etc).

Alex

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

Re: Move math algorithms from all projects to math libraries

[Alex Herbert]

On Tue, 18 Jul 2023 at 01:48, Dimitrios Efthymiou
 wrote:
>
> Thanks Gilles. I checked NUMBERS-193 and i have an implementation of DD and
> i will put it in *.ext package (TBD) along with some tests. Do i have to
> look at Dfd.java or something, because these dfd classes in math legacy
> core have lots of hard-coded decimals in there. Do these need to be copied
> to DD or just implement the high/low part, add, multiply and checks for
> overflows?

I am currently working on the implementation for this by porting what
I created for Statistics. If you can wait for this to be completed
then we can discuss the functionality and public API on the mailing
list or Jira ticket.

Alex

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

Re: Are any of these types of projects needed?

[Alex Herbert]

I would suggest you develop code that you will use. As volunteers we
have a main focus for our interests and put work in where we can, or
where it also benefits us back.

Contributions of large functionality are typically from an existing
project that would like to donate mature code to the ASF. This can go
through the process of becoming incorporated into the ASF as a new
project.

Contributions of small functionality are typically from a contributor
that had a specific need, could not find it in Java and created their
own. The Commons project is focused on all aspects of reusable Java
components. As such you can find similar functionality in other
programming languages. A contribution is more likely to be welcomed if
you can show examples of the same functionality in the core libraries
of other programming languages. This is a good acid test of what a
large number of programmers may require. For all of your suggestions
some feedback would be to put the question into a search engine: How
do I do ... in [Java|R|Matlab|Python|JavaScript|C++|etc]. If you find
Java has some missing topics then this could be a focus to start a
discussion on the dev mailing list.

Note that the ASF is not a place to host code that does not have
anyone using it. That is not productive to forming a developer
community.

Regards,

Alex


On Fri, 14 Jul 2023 at 02:21, Dimitrios Efthymiou
 wrote:
>
> The intended audience is the devs on this maillist. It is like market
> research to get the pulse of the community on these ideas to see if there
> is at least one that I could apply for in the incubator.
>
> No, i am not working on all of these. I just presented ideas so that I get
> some feedback. Maybe some people will say: "yes, an open source java-based
> eCommerce platform will be in demand", you know? Same with the other emails
> about math functions. Maybe some people from math or non-math commons
> libraries may point out that they would need some of those functions.
>
> Lastly, are there any math libraries that do symbolic math using functional
> interfaces? For example can I use commons math to give it a function that
> represents x^2, differentiate it and as a result get another function that
> represents 2x? I am talking about symbolic math that Wolfram Mathematica
> does.
>
> Thank you for the time you spent on going through the emails. I did some
> pull requests implementing some things and they kept being rejected. So, (i
> think it was you that suggested it) to ask the community which math
> functions they would like to see implemented
>
> On Fri, 14 Jul 2023, 02:03 Gilles Sadowski,  wrote:
>
> > Dimitrios,
> >
> > As requested several times, could you please add the "component"
> > prefix to the "Subject: " line, to signal to the intended audience?
> >
> > What's the purpose of the list below?
> > Are you developing all of those applications?
> >
> > Regards,
> > Gilles
> >
> > Le ven. 14 juil. 2023 à 02:54, Dimitrios Efthymiou
> >  a écrit :
> > >
> > > Java-based ECommerce platform
> > >
> > > Graph and network theory library
> > >
> > > Operations research or management science or mathematical programming
> > > library
> > >
> > > Calendar library with many useful methods that the java datetime API
> > > doesn't provide off-the-shelf
> > >
> > > Finance library including financial engineering
> > >
> > > User management (not apache shiro) i.e. account management, 2-factor
> > auth,
> > > forgot/reset password, security questions and more
> > >
> > > Web utilities from cookie service to device recognition to email service
> > > and more
> > >
> > > Image manipulation library
> > >
> > > Parallelism library for CPU and GPU parallelism
> > >
> > > Quantum computing library
> > >
> > > AdminTool platform. Imagine grafana, but with a lot of prebuilt and
> > > extensible tools
> > >
> > > Physics library
> > >
> > > Client SDK builder by taking API specs and generating java SDKs,
> > JavaScript
> > > SDKs, python etc.
> > >
> > > Transformer of MySQL data to MongoDB and vice-versa. Same for other kinds
> > > of databases
> > >
> > > Blockchain library
> > >
> > > Query Profiling Plugin: A plugin that tracks and logs all database
> > queries
> > > that are executed by the application. It could highlight inefficient
> > > queries, and also track and display query execution times.
> > >
> > > Health Check Plugin: A plugin to perform various health checks on the
> > > application and its dependencies, such as checking database connectivity,
> > > ensuring required services are running, checking disk space, etc. This
> > > plugin can expose health check endpoints that return the status of your
> > > application and its dependencies. This can be useful for monitoring and
> > > automated deployment scenarios.
> > >
> > > Scheduled Tasks Monitoring Plugin: This plugin could provide a unified
> > view
> > > of all the scheduled tasks in your application and provide information
> > like
> > > when each task last ran, whether it com

Re: [commons-lang] 02/02: Add IntToIntFunction

[Alex Herbert]

Is this not the same as:

java.util.function.IntUnaryOperator

On Mon, 10 Jul 2023 at 12:56,  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-lang.git
>
> commit 120d3489aad924e310a8071a66139947ace7a685
> Author: Gary Gregory 
> AuthorDate: Mon Jul 10 07:56:18 2023 -0400
>
> Add IntToIntFunction
> ---
>  src/changes/changes.xml|  1 +
>  .../commons/lang3/function/IntToIntFunction.java   | 52 
> ++
>  .../lang3/function/IntToIntFunctionTest.java   | 40 +
>  3 files changed, 93 insertions(+)
>
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index b9930b0d2..a9d493949 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -216,6 +216,7 @@ The  type attribute can be add,update,fix,remove.
>  Add and ExceptionUtils.isChecked() 
> and isUnchecked() #1069
>  Add and use ExceptionUtils.throwUnchecked(throwable).
>  Add LockingVisitors.create(O, ReadWriteLock).
> +Add IntToIntFunction.
>  
>   due-to="Dependabot, XenoAmess, Gary Gregory">Bump actions/cache from 2.1.4 to 
> 3.0.10 #742, #752, #764, #833, #867, #959, #964.
>   due-to="Dependabot, Gary Gregory">Bump actions/checkout from 2 to 3.1.0 #819, 
> #825, #859, #963.
> diff --git 
> a/src/main/java/org/apache/commons/lang3/function/IntToIntFunction.java 
> b/src/main/java/org/apache/commons/lang3/function/IntToIntFunction.java
> new file mode 100644
> index 0..45f309743
> --- /dev/null
> +++ b/src/main/java/org/apache/commons/lang3/function/IntToIntFunction.java
> @@ -0,0 +1,52 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +package org.apache.commons.lang3.function;
> +
> +import java.util.function.Function;
> +
> +/**
> + * Represents a function that accepts an int-valued argument and produces an 
> int-valued result. This is the {@code int}-to-{@code int} primitive 
> specialization
> + * for {@link Function}.
> + *
> + * 
> + * This is a functional interface whose 
> functional method is {@link #applyAsInt(int)}.
> + * 
> + *
> + * @see Function
> + * @since 3.13.0
> + */
> +@FunctionalInterface
> +public interface IntToIntFunction {
> +
> +/**
> + * Returns a function that always returns its input argument.
> + *
> + * @return a function that always returns its input argument
> + */
> +static IntToIntFunction identity() {
> +return i -> i;
> +}
> +
> +/**
> + * Applies this function to the given argument.
> + *
> + * @param value the function argument
> + * @return the function result
> + */
> +int applyAsInt(int value);
> +}
> diff --git 
> a/src/test/java/org/apache/commons/lang3/function/IntToIntFunctionTest.java 
> b/src/test/java/org/apache/commons/lang3/function/IntToIntFunctionTest.java
> new file mode 100644
> index 0..d8d11ae07
> --- /dev/null
> +++ 
> b/src/test/java/org/apache/commons/lang3/function/IntToIntFunctionTest.java
> @@ -0,0 +1,40 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +package org.apache.commons.lang3.function;
> +
> +import static org.junit.jupiter.api.Assertions.assertEquals;
> +
> +import org.apache.commons.lang3.AbstractLangTest;
> +import org.junit.jupiter.api.Test;
> +
> +/**

Re: [commons-lang] branch master updated: [LANG-1647] Add and ExceptionUtils.isChecked() and isUnchecked() #1069

[Alex Herbert]

On Mon, 3 Jul 2023 at 08:29, sebb  wrote:
>
> Is null checked or unchecked?
>
> I think neither, so isUnchecked also needs to check for null.
>
> I wonder whether it might be better to throw NPE in both cases for null.
>
> It may be confusing for users if not checked != unchecked.
> e.g. it is tempting to code:
>
> if (isChecked(t)) {
> } else { // must be unChecked
> }
>
> If we don’t throw NPE, then it needs to be made very clear that
> isChecked and isUnchecked are not opposites, there is a 3rd case.
>
> In any case, there needs to be a unit-test specifically for null.
>
> Sebb

+1

I reiterate what I originally said, this is missing:

@Test
public void testIsUnchecked_null() {
assertFalse(ExceptionUtils.isUnchecked(null));
}

The method implementation details are secondary to the fact that the
code is not clear on how it handles null; the relationship between
isChecked and isUnchecked; and the intended usage.

Note that one possible usage of type determination is to decide if you
can cast it to a certain type. Currently this method does not provide
this functionality as isUnchecked does not ensure that a cast to
RuntimeException is allowed (since it passes for Error). So my use
case is satisfied by instanceof. This leaves me wondering what are the
use cases for isChecked or isUnchecked. I presume you are in an
exception block with a Throwable of unknown type. So why do you care
if the exception is not checked if not for a recast?

Without a use case not satisfied by instanceof then this is code bloat.

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

Re: [commons-lang] branch master updated: [LANG-1647] Add and ExceptionUtils.isChecked() and isUnchecked() #1069

[Alex Herbert]

This change is not null-safe for isUnchecked. This case is missing
from the tests (and currently fails):

@Test
public void testIsUnchecked_null() {
assertFalse(ExceptionUtils.isUnchecked(null));
}

The case fails because it simply negates isChecked. Both methods
should return false when passed a null. Since instanceof handles null
then the isUnchecked method can be updated to:

public static boolean isUnchecked(final Throwable throwable) {
return (throwable instanceof Error) || (throwable instanceof
RuntimeException);
}

This implementation passes all current tests plus the extra one above.

On Sun, 2 Jul 2023 at 20:55,  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-lang.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 98ef0a413 [LANG-1647] Add and ExceptionUtils.isChecked() and 
> isUnchecked() #1069
> 98ef0a413 is described below
>
> commit 98ef0a4138ac032923c4fb12a97b388bde354668
> Author: Gary Gregory 
> AuthorDate: Sun Jul 2 15:55:12 2023 -0400
>
> [LANG-1647] Add and ExceptionUtils.isChecked() and isUnchecked() #1069
> ---
>  src/changes/changes.xml|   2 +
>  .../java/org/apache/commons/lang3/Functions.java   |   8 +-
>  .../commons/lang3/concurrent/ConcurrentUtils.java  |  21 +---
>  .../apache/commons/lang3/concurrent/Memoizer.java  |  10 +-
>  .../commons/lang3/exception/ExceptionUtils.java| 119 
> -
>  .../apache/commons/lang3/function/Failable.java|   8 +-
>  6 files changed, 77 insertions(+), 91 deletions(-)
>
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index 98a831c53..d4e0e4210 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -208,6 +208,8 @@ The  type attribute can be add,update,fix,remove.
>  Add Pair.accept(FailableBiConsumer).
>  Add Pair.apply(FailableBiFunction).
>  Add ReflectionDiffBuilder.setExcludeFieldNames(...) 
> and DiffExclude a… #838.
> +Add and ExceptionUtils.isChecked() 
> and isUnchecked() #1069
> +Add and use ExceptionUtils.throwUnchecked(throwable).
>  
>   due-to="Dependabot, XenoAmess, Gary Gregory">Bump actions/cache from 2.1.4 to 
> 3.0.10 #742, #752, #764, #833, #867, #959, #964.
>   due-to="Dependabot, Gary Gregory">Bump actions/checkout from 2 to 3.1.0 #819, 
> #825, #859, #963.
> diff --git a/src/main/java/org/apache/commons/lang3/Functions.java 
> b/src/main/java/org/apache/commons/lang3/Functions.java
> index e5e4e106c..7e0de8ba4 100644
> --- a/src/main/java/org/apache/commons/lang3/Functions.java
> +++ b/src/main/java/org/apache/commons/lang3/Functions.java
> @@ -33,6 +33,7 @@ import java.util.function.Supplier;
>  import java.util.stream.Stream;
>
>  import org.apache.commons.lang3.Streams.FailableStream;
> +import org.apache.commons.lang3.exception.ExceptionUtils;
>  import org.apache.commons.lang3.function.Failable;
>  import org.apache.commons.lang3.function.FailableBooleanSupplier;
>
> @@ -521,12 +522,7 @@ public class Functions {
>   */
>  public static RuntimeException rethrow(final Throwable throwable) {
>  Objects.requireNonNull(throwable, "throwable");
> -if (throwable instanceof RuntimeException) {
> -throw (RuntimeException) throwable;
> -}
> -if (throwable instanceof Error) {
> -throw (Error) throwable;
> -}
> +ExceptionUtils.throwUnchecked(throwable);
>  if (throwable instanceof IOException) {
>  throw new UncheckedIOException((IOException) throwable);
>  }
> diff --git 
> a/src/main/java/org/apache/commons/lang3/concurrent/ConcurrentUtils.java 
> b/src/main/java/org/apache/commons/lang3/concurrent/ConcurrentUtils.java
> index bafbad67d..42b6343da 100644
> --- a/src/main/java/org/apache/commons/lang3/concurrent/ConcurrentUtils.java
> +++ b/src/main/java/org/apache/commons/lang3/concurrent/ConcurrentUtils.java
> @@ -61,8 +61,7 @@ public class ConcurrentUtils {
>  if (ex == null || ex.getCause() == null) {
>  return null;
>  }
> -
> -throwCause(ex);
> +ExceptionUtils.throwUnchecked(ex.getCause());
>  return new ConcurrentException(ex.getMessage(), ex.getCause());
>  }
>
> @@ -84,7 +83,7 @@ public class ConcurrentUtils {
>  return null;
>  }
>
> -throwCause(ex);
> +ExceptionUtils.throwUnchecked(ex.getCause());
>  return new ConcurrentRuntimeException(ex.getMessage(), 
> ex.getCause());
>  }
>
> @@ -145,22 +144,6 @@ public class ConcurrentUtils {
>  return ex;
>  }
>
> -/**
> - * Tests whether the cause of the specified {@link ExecutionException}
> - * should be thrown and does it if necessary.
> - *
> - * @param ex the exception in question
> - */
> -   

Re: [COLLECTIONS] Thread safe Bloom filter

[Alex Herbert]

I do not think concurrent write usage is a general use case for the
filter. So this seems like a specialisation. If implementing it would
harm performance then I would be against it for the base
implementation.

For specialisation I would prefer the JDK pattern used for
Synchronized collections which have a class to wrap the underlying
implementation, e.g.

BloomFilters:
public static BloomFilter synchronizedBloomFilter(BloomFilter)
public static CountingBloomFilter
synchronizedCountingBloomFilter(CountingBloomFilter)

You can then make any implementation thread safe. If your suggested
solution would be to use a lock wrapping the entire method body then
the effect of a synchronized call wrapping the implementation is the
same. This would satisfy the use case of building a single filter
using multiple threads. Note however that the same can be achieved by
building multiple filters, 1 per thread, and then merging them all.

Note that it is dangerous to think that only some methods require
being synchronized. E.g. if a filter "contains" method does not alter
the internal state then it could be unsynchronized. But if a
concurrent thread changes the state then the result of the method call
can change. Those filters with complex internal state that may
reallocate memory will require synchronization around all methods,
e.g. SparseBloomFilter. Without this there may be concurrent
modification exceptions from internal data structures which are
traversed but may be updated concurrently.

For a SimpleBloomFilter there can be no structural modification after
construction (the internal backing array is final). But concurrent
writes may not be atomic and so data corruption can occur. For the
case of reads (i.e. calls to contains), the result is probabilistic
anyway so some error due to concurrent update while reading may be
acceptable.

What is your use case? It may be simpler to provide a static helper
class to wrap access to the methods you are using that can change the
filter (merge/cardinality). Your pool of threads can then call
'contains' without synchronization overhead and any threads that
update the filter use the helper:

// operations synchronized on the filter that is modified
// applies only to filters with no object reallocation on modification
static class FilterHelper {
boolean merge(BloomFilter bf1, BloomFilter bf2) {
synchronized (bf1) {
return bf1.merge(bf2);
}
}
}

Thus you effectively synchronize writes but do not restrict reads.
Some level of probabilistic error on read would have to be tolerated.

Alex

On Sun, 2 Jul 2023 at 07:40, Claude Warren  wrote:
>
> I have been thinking about what it would take to make SimpleBloomFilter
> thread safe.  I think that the answer is to use a copy on write strategy
> and a lock within all the merge methods.
>
> However, this leaves the problem of the cardinality calculation.  Currently
> it is lazily performed and cached.  I am thinking that there are 2
> solutions.
>
>1. mark cardinality volatile and leave the calculation as it effectively
>does a copy on write.
>2. update the cardinality inside the merge.  This should be doable as we
>can get the number of bits in each long after the merge and simply add them
>up during processing.
>
>
> Does anyone see a problem with this solution?
>
> Claude
> --
> 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: [VOTE] Release Apache Commons IO 2.12.0 based on RC2

[Alex Herbert]

Built from src zip using:

mvn install site

Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
Maven home: /Users/ah403/mvn/mvn
Java version: 17.0.6, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.3.1", arch: "aarch64", family: "mac"

I see 51 javadoc errors. Some are for private fields. But there are
many for public Builder and 12 for empty  tag (most probably using
 instead of ).

I see some coverage checks failing:

[WARNING] Rule violated for bundle commons-io: classes covered ratio
is 0.97, but expected minimum is 1.00
[WARNING] Rule violated for bundle commons-io: instructions covered
ratio is 0.88, but expected minimum is 0.90
[WARNING] Rule violated for bundle commons-io: methods covered ratio
is 0.89, but expected minimum is 0.95
[WARNING] Rule violated for bundle commons-io: branches covered ratio
is 0.81, but expected minimum is 0.85
[WARNING] Rule violated for bundle commons-io: lines covered ratio is
0.87, but expected minimum is 0.90
[WARNING] Rule violated for bundle commons-io: complexity covered
ratio is 0.83, but expected minimum is 0.85

These numbers (instructions covered; branche covered) are lower than
those reported on the live site report for 2.11. However the CodeCov
report [1] shows the same coverage since the start of reporting
(unfortunately just back to Apr 24) so this may be only a small
downward trend since the last release.

I believe all concerns with the new Builder for streams API were
addressed since the RC1 (I've been following the commits but did not
do a code deep dive). So these are all minor issues.

+1

Alex

[1] https://app.codecov.io/gh/apache/commons-io?search=&trend=30%20days

On Sat, 13 May 2023 at 16:24, 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 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/io/2.12.0-RC2 (svn
> revision 61825)
>
> The Git tag commons-io-2.12.0-RC2 commit for this RC is
> 266bcc4d5d0fbd230756539f93acd9fc5ddd2c5c which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-io.git;a=commit;h=266bcc4d5d0fbd230756539f93acd9fc5ddd2c5c
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-io.git
> --branch commons-io-2.12.0-RC2 commons-io-2.12.0-RC2
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1635/commons-io/commons-io/2.12.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sat May 13 11:10:37 EDT 2023
> commons-io-2.12.0-bin.tar.gz=24e41dec5dbdbd56d24c3d2ff294a1fecd4d0a80f1af2821ecf60da3527774aced1dca8d0752cebf444249cc4a207baf0fd6555e463b45879e02d0f03acc2445
> commons-io-2.12.0-bin.zip=03c1b6394a07b7b7ed36c97191891811985df9e89ce7369ac7e69d83e6491cc288755d33936ba45cb57fdac5addadf4b19b183b8f2ae52a0e1ee78157c80ea8d
> commons-io-2.12.0-bom.json=07c0b0c4112f54573606a7346699930850fef1274e848576c4a458edbcdd8b613c2cd6d54ab5f96a82a91875e8bbec41f9d50296dfea8558dd317c0ea0555b12
> commons-io-2.12.0-bom.xml=6fb6f96277ef2703bcb5d589bb6fdd1e7f8157d412ace264eb7a47ef0e245d9afa9ebf2b15b4e04b25fb600b37f6369a203ff90b33b904fd3869e48dc0a62069
> commons-io-2.12.0-javadoc.jar=af7ac2ef5439a3d744625917df048445ca6c867c8bef823d70f67a3c3509373b0f70dd4f37e1dd6b1e9ea9878d3a8596262f085ceb8f5255e5af868a9a19d231
> commons-io-2.12.0-sources.jar=a43e070c8b9f4b9a23bb3a6dd9bb5970d0bc8bc973e7fac707d35ac561738e785fffa92acca91483465539a3083fc36431ec09582fa0f98299848e795ff87ce2
> commons-io-2.12.0-src.tar.gz=0318e1566ed125a1d10a0a4f72895c0e7f0b1ad4f8704caec3a107b1755edaef6cd7502eb367c3b2b95e5ec46990b29c90e06cfe4da1cddd13cb9026bb5dee3a
> commons-io-2.12.0-src.zip=df6476b8a9b44746d71a617733048b1848612ec894564d413d92bc16426fe65a38cfbaa12c02140f76668220d9223f9e7d3c5b9a4c793fe14aff38540e0dd91a
> commons-io-2.12.0-test-sources.jar=594d19d76ab22e184fc962a4a3e4c91ff10e097cb5a8a52345a23b3b6d85e824f4844757d5c54f9d4d52a6e62687082d3685295f535d227b7a9586ea2444690b
> commons-io-2.12.0-tests.jar=86e392706ff98f04d053c4b3bbf1df5bb7a375f5ebcb1673ecdbedab36db627723937c93a6559944c19b516ce3b0f83d50143512dd2b891a1cc22524ee28c401
> commons-io_commons-io-2.12.0.spdx.json=071b3e127e1027587db04af620c406fd32ebb9810bd75936fd33131782b0c89417d83672f8ede5302eada044b4a2572b5dfbc598ca70a71695cad6fdea62d25a
>
> 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.9.2 (c9616018c7a021c1c39be70fb2843d6f5f9b8a1c)
> Maven home: /usr/local/Cellar/maven/3.9.2/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 loca

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

[Alex Herbert]

Validated signatures and checksums.

Build from source tar.gz file using 'mvn verify site' with:

Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
Maven home: /usr/local/apache-maven-3
Java version: 11.0.18, vendor: Ubuntu, runtime:
/usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-148-generic", arch: "amd64", family: "unix"

I do see the checkstyle and spotbugs report.

Spotbugs has a few mentions of non-serializable fields. This is
another case where we may not wish to support serialization going
forward (e.g. as with CSV). I cannot remember the solution for CSV. I
think it was a formal documentation that serialization will be dropped
in CSV 2.0. Looking at the error these are not new as the report in
the live site for 2.11.0 also has these.

Checked for the @since tag for new items in the japicmp report and
found no missing tags. I note that some of the new classes in package
io.build have no javadoc on inner classes with public constructors and
some static helper protected methods.

New helper classes with a private constructor should be final:

CharsetDecoders
CharsetEncoders
FilesUncheck
FileTimes

Changing public classes to final after a release breaks binary
compatibility. However other utility classes in the lib do not use
final for classes so this is not critical. FYI there are 5 others
which I found using PMD. The rule is
ClassWithOnlyPrivateConstructorsShouldBeFinal [1]. This is not part of
the default rules used in the project which is using the default from
the maven plugin [2]. If you run 'mvn pmd:check' the rules are written
to target/pmd/rulesets. I took these rules, added the extra rule and
then used this as the ruleset for PMD.

The new IOBiFunction has a noop method. This has no equivalent in
java.util.function.BiFunction. As discussed on a recent PR for Lang
(adding a noop to TriFunction) it does not make sense to have a noop
function that returns null as this is an operation. I assume this
BiFunction class was copied across from Lang bringing the noop with
it.

A minor inconsistency: QueueInputStream uses the new
AbstractStreamBuilder API but existing public constructors are not
deprecated. However other classes with equally simple constructors
(MemoryMappedFileInputStream, MessageDigestCalculatingInputStream,
etc) have deprecated their public constructors in favour of the
builder.

Documentation: The new AbstractStreamBuilder API exposes a lot of
public set methods in the builder. Some of these may not be applicable
to all use cases. The API allows an object for IO that is typically
created with either a Reader/Writer or Input/OutputStream, to also be
created with a Path or File. However creation using a Reader does not
support InputStream and vice versa. If a Reader is set then the Origin
will not be valid and a RTE will occur when opening the object which
tries to access the input stream from the Origin. Using the old API of
public constructors it was clear what the supported input arguments
were. All the Deprecated constructors that reference the new builder
would benefit from javadoc on the builder of the valid options that
can be configured.

The new classes UncheckedBufferedReader, UncheckedFilterInputStream,
UncheckedFilterReader, UnsynchronizedBufferedInputStream,
UnsynchronizedFilterInputStream, UncheckedFilterOutputStream do not
use the AbstractStreamBuilder API and have constructors. I think the
API can be applied in these cases, although many of the options would
be ignored (e.g. charset, buffer size, etc). However there may be a
reason that blocks use of the API that I did not notice (as I did not
try to implement it).

NullOutputStream deprecated constructor references deprecated
NULL_OUTPUT_STREAM singleton. Should be INSTANCE. Following on from
this should the NullPrintStream and NullWriter constructors also be
deprecated in favour of the INSTANCE?

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.

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.

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.

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  wrot

Re: [VOTE] Release Apache Commons Parent 57 based on RC2

[Alex Herbert]

+1

Installed from the tag. Builds Statistics (multi-module) and Lang
using Java 8 and 17.

Note: I do get this error from several plugins (pmd, site, bundle,
remote-resources):

[WARNING] Parameter 'localRepository' is deprecated core expression;
Avoid use of ArtifactRepository type. If you need access to local
repository, switch to '${repositorySystemSession}' expression and get
LRM from it instead.

Building using Maven 3.9.1. This property is not in the Statistics
project or CP. It is in lang for 'src/test/resources/java.policy'
which is for the Java Security Manager. So I assume the plugins are
attempting to perform a deprecated action via the Java Security
Manager.

Alex

On Sun, 23 Apr 2023 at 15:30, Gary Gregory  wrote:
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons Parent 56 was released, so I would like to release Apache
> Commons Parent 57.
>
> Apache Commons Parent 57 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/57-RC2
> (svn revision 61436)
>
> The Git tag commons-parent-57-RC2 commit for this RC is
> 21a0d410161312537687ab9188f9838af5bbd9e0 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=21a0d410161312537687ab9188f9838af5bbd9e0
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-57-RC2 commons-parent-57-RC2
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1632/org/apache/commons/commons-parent/57/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sun Apr 23 10:21:43 EDT 2023
> commons-parent-57-bom.json=465cc213bfafd2a47275ec9e7ada6ce7122486bce0c3e0191afd4b2dfb081a1bdd54d061bfc74e6911681d6470e87db54a785413099c495b4f69024bef6ad37f
> commons-parent-57-bom.xml=2bba4d662318246b268ad78cc5a1774b348ac98a826e17e5a31cfad6ebb20974842d25fe44ddb8785cbb4564411096ae02671d7ab1a76ae4d119f95a24ddf365
> commons-parent-57-site.xml=c6aea4f2c03920366bee23b08b046dacc09710e92c78ccd83f47cd92f89bc53abc3b8bbc7f44017ee94a2cb022ce763fe3f7d8c9aa42d571350269ba6568ca07
> commons-parent-57-src.tar.gz=fc57f72701b4e8d95a95fb972c8570c88e2976a9ac4270dea72bb961d46196ecdfee3cc9d5f7e18cf23a426412d0acdc15456955cd38707cd7ba3b34f877f2e6
> commons-parent-57-src.zip=cccd197f9bad7bdbe39ef91717533d1007666039144ae1ab29934e074208d360f69e0a28d733f0cb25210fce3a8bd10e7d0c8fdc7f6f373e4148d2a548c856a8
> org.apache.commons_commons-parent-57.spdx.json=6573ce664c4a0f0f940b649e77bd1ae4eb0130bdea29e6e861b50dfeb727bb73f22cdc708131b8accdfc44fc07a304ed51a47bf0d18632d2c4555f7e368f53e0
>
> 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.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: /usr/local/Cellar/maven/3.9.1/libexec
> Java version: 1.8.0_362, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8/1.8.0+362/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 56 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/57-RC2/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/57-RC2/site/changes-report.html
>
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/57-RC2/site/index.html
> (note some *relative* links are broken and the 57 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/57-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 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-57-RC2 commons-parent-57-RC2
> cd commons-parent-57-RC2
>
> 1b) Download and unpack the source archive from:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/57-RC2/source
>
> 2) Check Apache licenses
>
> This step is not required if the si

Re: [ALL] Eventually, soon, Java 11

[Alex Herbert]

Free commercial support for JDK 8 from Oracle ended in 2022.
Non-commercial and extended commercial support ends in 2030. Other
providers have free support for longer than 2023 [1]. I would rather
maintain Java 8 support when JDK 8 still has broad support and usage.

Alex

[1] https://en.wikipedia.org/wiki/Java_version_history

On Sun, 23 Apr 2023 at 14:50, Alex Remily  wrote:
>
> Gary,
>
> A few years ago I migrated commons crypto onto Java 11 in my local
> environment.  I haven't kept the code, but it wasn't a heavy lift and I'm
> happy to do it again for the community version.  Let me know how you'd like
> me to proceed.
>
> Alex
>
> On Sun, Apr 23, 2023 at 9:47 AM Gary Gregory  wrote:
>
> > Hi All,
> >
> > In the year 2023, and with Java 21 in EA (https://jdk.java.net/21/), I
> > think it is time to start migrating our components from Java 8 to Java
> > 11. I imagine this to happen slowly and surely over the course of this
> > whole year.
> >
> > In addition, originally, it should also be time to update our GitHub
> > builds to run on Java 21-EA.
> >
> > 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][LAZY] Release Apache Commons Parent 57 based on RC1

[Alex Herbert]

Installed from the git tag. I can build projects on JDK 11 and 17. But
not on JDK 8.

The new profile to conditionally configure the maven-compiler-release
plugin for JDK 9+ is incorrect. The parent pom defines the property:


8

Then activates it using:


  jdk9-compiler
  
[9,)
  
  

  

  org.apache.maven.plugins
  maven-compiler-plugin
  
${maven.compiler.release}
  

  

  


However the use of the property  is enough to
set it into the compiler-plugin when building on JDK 8. I see the
following error when building under JDK 8:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile
(default-compile) on project commons-lang3: Fatal error compiling:
invalid flag: --release -> [Help 1]

I note that the config is actually recommended on the maven
documentation for the plugin [1]. However it seems that just setting
this property (given that it is the user override property for the
 tag [2]) enables it on JDK 8. Perhaps this is an error in
the maven-compiler-plugin itself.

In Commons Geometry the configuration uses a unique property on the
POM and then sets maven.compiler.release for JDK 9+:


8


compiler-release-property

[9,)



${jvm.target}



I switched to this setup in CP 57 and the build on JDK 8 worked. So
perhaps we should change to this pattern and provide feedback to the
maven-compiler-plugin developers that their recommended configuration
does not work.

Other notes:

1. I still get a warning from the SPDX plugin (same as previous versions of CP):

[WARNING] Unable to map maven licenses to a declared license.  Using NOASSERTION

I do not know where this comes from. The ASF 2.0 license should be
recognised. This seems to output for all projects including building
CP itself. Looking at the config options for SPDX this should
automatically recognise the ASF license so I do not know if this is a
config problem or a bug in SPDX.


2. I had problems with commons-lang on a new Mac processor:

Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
Maven home: /Users/ah403/mvn/mvn
Java version: 17.0.6, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.3.1", arch: "aarch64", family: "mac"

Using JDK 11 or 17 I get a failure in a unit test for
ArchUtilsTest.testGetProcessor. The test assumes that the current
architecture is x86. As shown above the architecture is "aarch64". The
problem is with the test which should be more robust to actually
knowing what the architecture is before asserting it is x86. This is
not an issue with the parent.

Note that the "os.arch" property on JDK 8 does not detect the new
apple architecture:

Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
Maven home: /Users/ah403/mvn/mvn
Java version: 1.8.0_362, vendor: Temurin, runtime:
/Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.3.1", arch: "x86_64", family: "mac"

So when building on JDK 8 this test passes as the arch is detected as
"x86". The test in lang should be more robust, perhaps just commenting
out the invalid assertion on line 128 would be enough:

final Processor processor = ArchUtils.getProcessor();
assertTrue(processor.isX86());  // <--  This is not platform safe

Regards,

Alex

[1] 
https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html
[2] 
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release

On Sat, 22 Apr 2023 at 15:25, Gary Gregory  wrote:
>
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Parent 56 was released, so I would like to
> release Apache Commons Parent 57.
>
> Apache Commons Parent 57 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/57-RC1
> (svn revision 61424)
>
> The Git tag commons-parent-57-RC1 commit for this RC is
> 438328ae7ef71feb9565c650c2d83404c191c031 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=438328ae7ef71feb9565c650c2d83404c191c031
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-57-RC1 commons-parent-57-RC1
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1631/org/apache/commons/commons-parent/57/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sat Apr 22 10:17:35 EDT 2023
> commons-parent-57-bom.json=4939a0314f700a40eb479eb4ad62a835c188238f683be41120ff7

Re: [all] Failed Jenkins builds

[Alex Herbert]

On Mon, 20 Mar 2023 at 10:26, Gary Gregory  wrote:
>
> All Commons components are Java 8 (or older), so all could be disabled? I
> only rely on GitHub builds since it validates PRs. There is a way to make
> releases from GH but I've not looked into it yet.

I do not want to waste my time fixing something that is not required.
I'd rather just turn them off for now and they can be fixed if needed
in the future.

I will configure the math derived multi-module components to run under
JDK 11 as snapshot deployment is useful. The SonarCloud analysis
already requires JDK 11 so these builds are fine.

Alex

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

[all] Failed Jenkins builds

[Alex Herbert]

A recent update in Jenkins has updated some part of the Jenkins
tooling that reports on the job to a jar file compiled for Java 11.
This is making all the Java 8 Jenkins jobs fail.

I am not sure of the relevance of many of these Jenkins builds given
the use of GH actions for CI builds. The advantage of Jenkins builds
is to deploy SNAPSHOTS automatically to the snapshot repo. This is
useful for mutli-module projects where you are able to do a build
within one module from the current dev branch and the other
dependencies are pulled from the snapshot repo. It can also be used to
run the SonarCloud code quality analysis.

I suggest disabling the following builds that are failing due to Java
11 incompatibility in the job setup:

- commons-bcel
- commons-build-plugin
- commons-cli
- commons-codec
- commons-configuration
- commons-imaging
- commons-io
- commons-parent
- commons-validator

The configuration can be fixed if snapshot deployment is required in the future.

Alex

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

[numbers][GSoC2023] About “Add support for extended precision floating-point numbers” project

[Alex Herbert]

FYI: I added the [numbers] prefix to the subject line.



> > ・ I read David Bailey's paper on the QD library and understood its
> > algorithms. I also briefly looked over its C++ implementation.

This is where I would start with an API design. E.g. what OO API does
the c++ reference implementation provide?

I do not think we want to replace the functionality in the Sum class.
This is a specialised class for linear combinations. The DD class
would be a more general number to be used as you would use a double or
a BigDecimal. I would imagine the API would consist of methods acting
on the current instance and returning a new instance:

DD add(DD)
DD subtract(DD)
DD multiply(DD)
DD divide(DD)

Overrides could be provided for int/long/double arguments as these
have useful simplifications over adding a full double-double number.

Other methods from the current statistics implementation are:

DD pow(int)
DD inverse()

DD ldexp(int)
(int, DD) frexp()  ???

The later are useful for scaling where the exponent range of a double
is effectively limited to [-1074, 1023] in base 2; without sub-normal
numbers this is -1022.

The frexp method is somewhat problematic as there are two return
values. A new normalised fraction in [0.5, 1) and the base 2 scale of
the normalised number. It could be implemented as:

DD frexp(int[] exp)

Other methods for a number could be e.g.:

DD negate()

> > ・ Implement QD as well as DD. As briefly mentioned in the David Bailey
> > paper, for many applications, the use of DD or QD is sufficient.
> > Therefore, I do not think implementing arbitrary-length floating-point
> > numbers is necessary.

Perfectly fine. Other variants can be added later if required.

> > And my question is, what specific extensions do you think are needed
> > regarding the existing double-double API?

The key point of the current API is that it requires no memory
allocation within the class. As such the class has been written to be
mutable. All methods act on primitives and write results to an output
argument. However this does not fully encapsulate the functionality
and methods may be called with arguments that are not normalised
double-double numbers. As such it is open to incorrect usage. For a
public class this either should not be done, or it should be provided
as an alternative to the friendly OO API for advanced usage.

I wrote the implementation this way to avoid memory allocation of a
new object for every operation. I do not know if it actually impacts
the performance. A first project would be to: copy the entire DD class
into a JMH project; add OO methods that create a new instance for all
operations; and copy/adapt the Kolmogorov-Smirnov p-value computation
from statistics for the non-OO and OO API. For a large p-value
computation the current method takes up to 1 second and would create
approximately 50 million objects for intermediate computations (my
guesstimate). The present implementation creates 3 objects. It would
be a useful test to determine if this object creation and garbage
collection affects the performance.

> > Also, how about my ideas on extending the API to be more
> > user-friendly? Am I on the right way?

Perhaps focus on what API is in the c++ library. I imagine this is
fairly mature and will provide a good example of an API of how to
manipulate a custom number implementation.

> Sure; your questions are certainly part of the issues that need
> clarification.
> However, besides the functionality itself, there is the question of
> how it fits within the (math-related) components' "eco-system".
> By this I mean that the code should be moved to "[Numbers]", but
> where?  In the "core" module (where "Sum" is implemented), or in
> a new module of its own (e.g. on the assumption that it may be
> too specific a utility)?
> For one thing, the "Statistics" component will surely depend on
> that utility; hence, porting the existing code to "[Numbers]" might
> be your first pull request[1] (after ensuring locally that the calling
> code is "Statistics" still works as it used to).
>
> Thus, please create a JIRA report[2] to further elaborate on this.[3]

I think a new numbers module for a DD implementation makes sense. We
already have modules for fractions and complex numbers.

Feel free to add some comments on the initial Jira ticket summarising
this direction. We can then create sub-tickets for tasks that you wish
to tackle (e.g. JMH benchmark the current DD class; describe an
initial API for a DD class).

Alex

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

Re: [math] The build is broken

[Alex Herbert]

Is it consistently broken? One test for the optimisers requires 15 restarts
due to randomness in the optimiser and the difficulty of the optimisation
problem. This runs in a different phase. See the surefire plug-in
configuration in the math parent pom.

We tried to make the test suite more robust but you still get failures.
Gilles did a lot of work on the simplex tests which by their nature are
random in their search process. The rest of the test suite runs with up to
5 retries and sporadically fails. But most of the time what we have will
pass so I did not move more tests to the difficulty to pass group. If you
check the build log you can see if the build failed on one of these
optimisation tests or if it is failing somewhere else.

Alex


On Sat, 4 Mar 2023, 15:21 sebb,  wrote:

> On Sat, 4 Mar 2023 at 15:16, Gary Gregory  wrote:
> >
> > Let me get this straight: You use Gmail but you refuse to sign in to
> > GitHub? Right...
>
> So what?
>
> They are run by different organisations.
> The consequences of a leak are very different, especially if you only
> use GMail for public mails.
>
> Let people choose what 3rd party services they want to use.
>
> > Gary
> >
> > On Sat, Mar 4, 2023, 10:11 Gilles Sadowski  wrote:
> >
> > > Hello Gary.
> > >
> > > Le sam. 4 mars 2023 à 15:52, Gary D. Gregory  a
> > > écrit :
> > > >
> > > > 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
> > >
> > > Thanks for the notice but a button says "Sign in to view logs".
> > > No-go.
> > >
> > > >
> > > > Please fix.
> > >
> > > Could you please post the logs in a JIRA report?
> > >
> > > Two builds in a row were successful here:
> > >
> > > $ git pull
> > > Already up to date.
> > > $ mvn
> > > [...]
> > > [INFO] Reactor Summary for Apache Commons Math 4.0-SNAPSHOT:
> > > [INFO]
> > > [INFO] Apache Commons Math  SUCCESS [
> > > 4.842 s]
> > > [INFO] Miscellaneous core classes . SUCCESS [
> > > 15.431 s]
> > > [INFO] Artificial neural networks . SUCCESS [
> > > 9.253 s]
> > > [INFO] Transforms . SUCCESS [
> > > 7.217 s]
> > > [INFO] Exception classes (Legacy) . SUCCESS [
> > > 7.430 s]
> > > [INFO] Miscellaneous core classes (Legacy)  SUCCESS [
> > > 16.820 s]
> > > [INFO] Apache Commons Math (Legacy) ... SUCCESS
> [01:24
> > > min]
> > > [INFO] Apache Commons Math Documentation .. SUCCESS [
> > > 5.144 s]
> > > [INFO] Example applications ... SUCCESS [
> > > 0.212 s]
> > > [INFO] SOFM ... SUCCESS [
> > > 0.274 s]
> > > [INFO] SOFM: Chinese Rings  SUCCESS [
> > > 5.772 s]
> > > [INFO] SOFM: Traveling Salesman Problem ... SUCCESS [
> > > 5.743 s]
> > > [INFO] K-Means  SUCCESS [
> > > 0.487 s]
> > > [INFO] K-Means: Image Clustering .. SUCCESS [
> > > 5.322 s]
> > > [INFO]
> > >
> 
> > > [INFO] BUILD SUCCESS
> > > [INFO]
> > >
> 
> > > [INFO] Total time:  02:48 min
> > > [INFO] Finished at: 2023-03-04T16:05:58+01:00
> > > [INFO]
> > >
> 
> > >
> > > Regards,
> > > Gilles
> > >
> > > >
> > > > 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
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>