[VOTE] Release Apache Commons RNG 1.3 based on RC1

[Alex Herbert <ah...@apache.org>]

We have fixed quite a few bugs and added some significant enhancements 
since Apache Commons RNG 1.2 was released, so I would like to release 
Apache Commons RNG 1.3.

Apache Commons RNG 1.3 RC1 is available for review here:
   https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/
   https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/

Tag name:
   RNG_1_3_RC1 (signature can be checked from git using 'git tag -v 
RNG_1_3_RC1')

Tag URL:
https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=43f290e68c31e5bea6cde97c7e999c2e1f2562b2

Commit ID the tag points at:
   43f290e68c31e5bea6cde97c7e999c2e1f2562b2

Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1476/org/apache/commons/

These are the artifacts and their SHA 512 hashes:
310c0582b80c60fb159846f9615c7952b3c405265955392d77b16d7cfac9e8c5f2c680686e526b412ab8b4356ef9ecd07977764c31db8e02bef40e37b47ac27a 
commons-rng-1.0-bin.tar.gz
e0247ea82aff57cc86ac904ae482c193b7edd5253d26f87fc590b50a738d5fa5c4a6b3b24cd6a48c459e18156ade2588d8c9d12c9a04d15570780240d29ef406 
commons-rng-1.0-bin.zip
f33b922a9d8bc6098bd0e9a98859b17e1cdda21922f136b568868b21af274fdf3d78456a5c73c26c665205a22493836d59b1d33822c4a5c58e82ba64eadcb5e1 
commons-rng-1.0-src.tar.gz
ef4fe63ebbd76e8d95b5f054fed76a40a85f5dd99ca2406a31fb95b593ed3d96b29389bf82424e18895192751689d7590404c8b1d90b28878271c79cad3be18b 
commons-rng-1.0-src.zip

The source code contains examples that are not part of the public API. 
These examples contain Java 9 modules and are enabled using a profile 
(see below).

An error when building the Java 9 modules site/javadoc under JDK 11 is a 
known issue as the javadoc command errors when documenting Java 9 
modules that include code from the unamed module.

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 site' using:

***
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T19:41:47+01:00)
Maven home: /usr/local/apache-maven-3.6.0
Java version: 1.8.0_222, vendor: Private Build, runtime: 
/usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
"unix"
***

***
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T19:41:47+01:00)
Maven home: /usr/local/apache-maven-3.6.0
Java version: 11.0.5, vendor: AdoptOpenJDK, runtime: 
/usr/lib/jvm/jdk-11.0.5+10
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
"unix"
***

Java 9 modules in the examples modules.

'mvn -Pcommons-rng-examples clean install site' using:

***
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T19:41:47+01:00)
Maven home: /usr/local/apache-maven-3.6.0
Java version: 9, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-9
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
"unix"
***

'mvn -Pcommons-rng-examples clean install' using:

***
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T19:41:47+01:00)
Maven home: /usr/local/apache-maven-3.6.0
Java version: 11.0.5, vendor: AdoptOpenJDK, runtime: 
/usr/lib/jvm/jdk-11.0.5+10
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
"unix"
***

Details of changes since 1.2 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/RELEASE-NOTES.txt
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/changes-report.html

Site:
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/index.html
     (note some *relative* links are broken and the 1.3 directories are 
not yet created - these will be OK once the site is deployed.)

CLIRR Report (compared to 1.2):
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-client-api/clirr-report.html
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-core/clirr-report.html
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-simple/clirr-report.html
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-sampling/clirr-report.html

RAT Report:
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/rat-report.html

KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

Thank you,

Alex Herbert,
Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==============================

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-rng.git --branch 
RNG_1_3_RC1 commons-rng-1.3-RC1
cd commons-rng-1.3-RC1

2) Check Apache licenses

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

mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

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

mvn clirr:check

JApiCmp is not used in this component.


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

-the end-


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

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

[Pascal Schumacher <pa...@gmx.net>]

+1

Am 05.11.2019 um 17:36 schrieb Alex Herbert:
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons RNG 1.2 was released, so I would like to release
> Apache Commons RNG 1.3.
>
> Apache Commons RNG 1.3 RC1 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/
>   https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/
>
> Tag name:
>   RNG_1_3_RC1 (signature can be checked from git using 'git tag -v
> RNG_1_3_RC1')
>
> Tag URL:
> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=43f290e68c31e5bea6cde97c7e999c2e1f2562b2
>
>
> Commit ID the tag points at:
>   43f290e68c31e5bea6cde97c7e999c2e1f2562b2
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1476/org/apache/commons/
>
>
> These are the artifacts and their SHA 512 hashes:
> 310c0582b80c60fb159846f9615c7952b3c405265955392d77b16d7cfac9e8c5f2c680686e526b412ab8b4356ef9ecd07977764c31db8e02bef40e37b47ac27a
> commons-rng-1.0-bin.tar.gz
> e0247ea82aff57cc86ac904ae482c193b7edd5253d26f87fc590b50a738d5fa5c4a6b3b24cd6a48c459e18156ade2588d8c9d12c9a04d15570780240d29ef406
> commons-rng-1.0-bin.zip
> f33b922a9d8bc6098bd0e9a98859b17e1cdda21922f136b568868b21af274fdf3d78456a5c73c26c665205a22493836d59b1d33822c4a5c58e82ba64eadcb5e1
> commons-rng-1.0-src.tar.gz
> ef4fe63ebbd76e8d95b5f054fed76a40a85f5dd99ca2406a31fb95b593ed3d96b29389bf82424e18895192751689d7590404c8b1d90b28878271c79cad3be18b
> commons-rng-1.0-src.zip
>
> The source code contains examples that are not part of the public API.
> These examples contain Java 9 modules and are enabled using a profile
> (see below).
>
> An error when building the Java 9 modules site/javadoc under JDK 11 is
> a known issue as the javadoc command errors when documenting Java 9
> modules that include code from the unamed module.
>
> 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 site' using:
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 1.8.0_222, vendor: Private Build, runtime:
> /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
> "unix"
> ***
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
> /usr/lib/jvm/jdk-11.0.5+10
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
> "unix"
> ***
>
> Java 9 modules in the examples modules.
>
> 'mvn -Pcommons-rng-examples clean install site' using:
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 9, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-9
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
> "unix"
> ***
>
> 'mvn -Pcommons-rng-examples clean install' using:
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
> /usr/lib/jvm/jdk-11.0.5+10
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
> "unix"
> ***
>
> Details of changes since 1.2 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/RELEASE-NOTES.txt
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/changes-report.html
>
>
> Site:
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/index.html
>     (note some *relative* links are broken and the 1.3 directories are
> not yet created - these will be OK once the site is deployed.)
>
> CLIRR Report (compared to 1.2):
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-client-api/clirr-report.html
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-core/clirr-report.html
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-simple/clirr-report.html
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-sampling/clirr-report.html
>
>
> RAT Report:
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/rat-report.html
>
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Alex Herbert,
> Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==============================
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-rng.git --branch
> RNG_1_3_RC1 commons-rng-1.3-RC1
> cd commons-rng-1.3-RC1
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which
> you then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Older components still use Apache Clirr:
>
> This step is not required if the site includes a Clirr report page
> which you then must check.
>
> mvn clirr:check
>
> JApiCmp is not used in this component.
>
>
> 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
>
> -the end-
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


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

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

[Alex Herbert <al...@gmail.com>]

Here's my +1.

Alex

On 05/11/2019 16:36, Alex Herbert wrote:
> We have fixed quite a few bugs and added some significant enhancements 
> since Apache Commons RNG 1.2 was released, so I would like to release 
> Apache Commons RNG 1.3.
>
> Apache Commons RNG 1.3 RC1 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/
>   https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/
>
> Tag name:
>   RNG_1_3_RC1 (signature can be checked from git using 'git tag -v 
> RNG_1_3_RC1')
>
> Tag URL:
> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=43f290e68c31e5bea6cde97c7e999c2e1f2562b2 
>
>
> Commit ID the tag points at:
>   43f290e68c31e5bea6cde97c7e999c2e1f2562b2
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1476/org/apache/commons/ 
>
>
> These are the artifacts and their SHA 512 hashes:
> 310c0582b80c60fb159846f9615c7952b3c405265955392d77b16d7cfac9e8c5f2c680686e526b412ab8b4356ef9ecd07977764c31db8e02bef40e37b47ac27a 
> commons-rng-1.0-bin.tar.gz
> e0247ea82aff57cc86ac904ae482c193b7edd5253d26f87fc590b50a738d5fa5c4a6b3b24cd6a48c459e18156ade2588d8c9d12c9a04d15570780240d29ef406 
> commons-rng-1.0-bin.zip
> f33b922a9d8bc6098bd0e9a98859b17e1cdda21922f136b568868b21af274fdf3d78456a5c73c26c665205a22493836d59b1d33822c4a5c58e82ba64eadcb5e1 
> commons-rng-1.0-src.tar.gz
> ef4fe63ebbd76e8d95b5f054fed76a40a85f5dd99ca2406a31fb95b593ed3d96b29389bf82424e18895192751689d7590404c8b1d90b28878271c79cad3be18b 
> commons-rng-1.0-src.zip
>
> The source code contains examples that are not part of the public API. 
> These examples contain Java 9 modules and are enabled using a profile 
> (see below).
>
> An error when building the Java 9 modules site/javadoc under JDK 11 is 
> a known issue as the javadoc command errors when documenting Java 9 
> modules that include code from the unamed module.
>
> 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 site' using:
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 1.8.0_222, vendor: Private Build, runtime: 
> /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
> "unix"
> ***
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime: 
> /usr/lib/jvm/jdk-11.0.5+10
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
> "unix"
> ***
>
> Java 9 modules in the examples modules.
>
> 'mvn -Pcommons-rng-examples clean install site' using:
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 9, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-9
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
> "unix"
> ***
>
> 'mvn -Pcommons-rng-examples clean install' using:
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime: 
> /usr/lib/jvm/jdk-11.0.5+10
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
> "unix"
> ***
>
> Details of changes since 1.2 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/RELEASE-NOTES.txt 
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/changes-report.html 
>
>
> Site:
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/index.html
>     (note some *relative* links are broken and the 1.3 directories are 
> not yet created - these will be OK once the site is deployed.)
>
> CLIRR Report (compared to 1.2):
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-client-api/clirr-report.html 
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-core/clirr-report.html 
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-simple/clirr-report.html 
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-sampling/clirr-report.html 
>
>
> RAT Report:
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/rat-report.html 
>
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Alex Herbert,
> Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==============================
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-rng.git --branch 
> RNG_1_3_RC1 commons-rng-1.3-RC1
> cd commons-rng-1.3-RC1
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which 
> you then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Older components still use Apache Clirr:
>
> This step is not required if the site includes a Clirr report page 
> which you then must check.
>
> mvn clirr:check
>
> JApiCmp is not used in this component.
>
>
> 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
>
> -the end-
>

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

[RESULT][VOTE] Release Apache Commons RNG 1.3 based on RC1

[Alex Herbert <al...@gmail.com>]

The votes are as follows:

+1 - Gilles Sadowski (binding)
+1 - Pascal Schumacher (binding)
+1 - Alex Herbert (binding)

I will perform the release now. Many thanks to the validators.

Alex

On 05/11/2019 16:36, Alex Herbert wrote:
> We have fixed quite a few bugs and added some significant enhancements 
> since Apache Commons RNG 1.2 was released, so I would like to release 
> Apache Commons RNG 1.3.
>
> Apache Commons RNG 1.3 RC1 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/
>   https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/
>
> Tag name:
>   RNG_1_3_RC1 (signature can be checked from git using 'git tag -v 
> RNG_1_3_RC1')
>
> Tag URL:
> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=43f290e68c31e5bea6cde97c7e999c2e1f2562b2 
>
>
> Commit ID the tag points at:
>   43f290e68c31e5bea6cde97c7e999c2e1f2562b2
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1476/org/apache/commons/ 
>
>
> These are the artifacts and their SHA 512 hashes:
> 310c0582b80c60fb159846f9615c7952b3c405265955392d77b16d7cfac9e8c5f2c680686e526b412ab8b4356ef9ecd07977764c31db8e02bef40e37b47ac27a 
> commons-rng-1.0-bin.tar.gz
> e0247ea82aff57cc86ac904ae482c193b7edd5253d26f87fc590b50a738d5fa5c4a6b3b24cd6a48c459e18156ade2588d8c9d12c9a04d15570780240d29ef406 
> commons-rng-1.0-bin.zip
> f33b922a9d8bc6098bd0e9a98859b17e1cdda21922f136b568868b21af274fdf3d78456a5c73c26c665205a22493836d59b1d33822c4a5c58e82ba64eadcb5e1 
> commons-rng-1.0-src.tar.gz
> ef4fe63ebbd76e8d95b5f054fed76a40a85f5dd99ca2406a31fb95b593ed3d96b29389bf82424e18895192751689d7590404c8b1d90b28878271c79cad3be18b 
> commons-rng-1.0-src.zip
>
> The source code contains examples that are not part of the public API. 
> These examples contain Java 9 modules and are enabled using a profile 
> (see below).
>
> An error when building the Java 9 modules site/javadoc under JDK 11 is 
> a known issue as the javadoc command errors when documenting Java 9 
> modules that include code from the unamed module.
>
> 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 site' using:
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 1.8.0_222, vendor: Private Build, runtime: 
> /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
> "unix"
> ***
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime: 
> /usr/lib/jvm/jdk-11.0.5+10
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
> "unix"
> ***
>
> Java 9 modules in the examples modules.
>
> 'mvn -Pcommons-rng-examples clean install site' using:
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 9, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-9
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
> "unix"
> ***
>
> 'mvn -Pcommons-rng-examples clean install' using:
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime: 
> /usr/lib/jvm/jdk-11.0.5+10
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
> "unix"
> ***
>
> Details of changes since 1.2 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/RELEASE-NOTES.txt 
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/changes-report.html 
>
>
> Site:
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/index.html
>     (note some *relative* links are broken and the 1.3 directories are 
> not yet created - these will be OK once the site is deployed.)
>
> CLIRR Report (compared to 1.2):
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-client-api/clirr-report.html 
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-core/clirr-report.html 
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-simple/clirr-report.html 
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-sampling/clirr-report.html 
>
>
> RAT Report:
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/rat-report.html 
>
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Alex Herbert,
> Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==============================
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-rng.git --branch 
> RNG_1_3_RC1 commons-rng-1.3-RC1
> cd commons-rng-1.3-RC1
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which 
> you then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Older components still use Apache Clirr:
>
> This step is not required if the site includes a Clirr report page 
> which you then must check.
>
> mvn clirr:check
>
> JApiCmp is not used in this component.
>
>
> 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
>
> -the end-
>

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

Re: [RNG] Site layout for modular components (Was: Release [...] RNG [...])

[Gilles Sadowski <gi...@gmail.com>]

Hi.

Le jeu. 14 nov. 2019 à 13:12, Alex Herbert <al...@gmail.com> a écrit :
>
>
> On 14/11/2019 01:39, Gilles Sadowski wrote:
> > 2019-11-14 1:35 UTC+01:00, Alex Herbert <al...@gmail.com>:
> >>
> >>> On 13 Nov 2019, at 23:53, Gilles Sadowski <gi...@gmail.com> wrote:
> >>>
> >>> Hello.
> >>>
> >>> Le mer. 13 nov. 2019 à 18:29, Alex Herbert <alex.d.herbert@gmail.com
> >>> <ma...@gmail.com>> a écrit :
> >>>>
> >>>> On 13/11/2019 13:09, Gilles Sadowski wrote:
> >>>>> Hi.
> >>>>>
> >>>>> Do you think that it would be feasible to have all those fixes applied
> >>>>> to other modular components (that were based on the [RNG] layout)
> >>>>> through a common layer (another POM) between those components
> >>>>> and "commons-parent"?
> >>>> Most of the fixes have been in the module site descriptors or items that
> >>>> should be moved up to commons parent. It may be possible to put the site
> >>>> descriptors into a parent. IIUC the site descriptors are merged together
> >>>> before the maven site plugin creates the site. So the fix for the top
> >>>> right banner could be moved into a common parent. Each child module
> >>>> would also want to enumerate the past releases of the javadocs. Thus
> >>>> they would require a site descriptor anyway and the banner fix would
> >>>> only save 5 lines per site.xml for the banner.
> >>> Well, I was thinking of whether a multi-layered POM could be more
> >>> flexible and robust in handling the different type of components (e.g.
> >>> "multi-module" or not).
> >> I think this would take a bit more reading on exactly how Maven thinks a
> >> multi-module project should work...
> > Probably. :-/
> >
> >>>> I did a big change to the use of svn to checkout the current site. This
> >>>> was required as the archived javadocs are not in a top level directory.
> >>>> So each module has to be checked out, the archived javadocs set to be
> >>>> excluded and then the rest of the site can be checked out.
> >>> Sorry, I don't follow.
> >>> Didn't links to the Javadoc of previous versions exist prior to those
> >>> changes?
> >> Yes. Take a look at the pom.xml on line 464 for prepare-checkout.
> >>
> >> This entire section was and is a mystery to me. I don’t know why it is
> >> required to create a copy of the site locally.
> > Oh, I seem to remember now that I was hit by this nonsense of
> > svn checking out the web site when the "site-content" did not
> > exist!
> >
> >> The previous code in this maven target was created on the assumption that it
> >> was a single module project and the archived javadocs for every previous
> >> version were in a javadocs directory under the top level directory. The same
> >> code is present in lang, io, text, etc.
> >>
> >> The way it works for those projects is incorrect for a multi-module site as
> >> the archived javadocs are in a different place. It also is a target run in
> >> every module and so for a full site build with the examples modules you
> >> ended up with 14 full checkout copies of the RNG site, including the old
> >> archived javadocs.
> > Not sure I get what you mean; but I don't think that anything related
> > to svn should be necessary in the POM file, excerpt perhaps to automate
> > the creation of an *empty* "site-content" directory (in every module)
> > in order to prevent downloading the web site.
> >
> >> Anyway I fixed it to work as it should. It checks out the site and ignores
> >> the old javadocs. I added a fix so child modules copy the parent site
> >> checkout. This only works if invoked in two stages on a clean git checkout:
> >>
> >> mvn -N pre-site && mvn pre-site
> >>
> >> This in itself is annoying as you cannot do:
> >>
> >> git clone …
> >> cd commons-rng && mvn site
> >>
> >> Without the checkout of the site in each module. I think I can fix this by
> >> using an external ant build.xml file where you can do if-else logic. But I
> >> was wondering if I even had to. Perhaps the goal only needs to run in the
> >> parent, or the dist-archive module for a release.
> > Not even there (IIUC whet you mean).
> > What I do is something along the lines:
> >   $ mvn site site:stage
> >   $ cd site-content
> >   $ rm -rf *
> >   $ cd target/staging
> >   $ cp -r . ../../site-content
> > Then
> >   $ cd ../../site-content
> >   $ svn add ... the new files (shown with "?" by "svn status")
> >   $ svn del ... the old files (shown with "!" by "svn status")
> >   $ svn commit
> >
> >> What I would like to know is:
> >>
> >> 1. Do the child modules need this?
> > I don't think so.
> >
> >> 2. What is it used for? If it is only for a release then it should be in the
> >> release profile. Or maybe the commons-release plugin. Using ant to do this
> >> external execution is just poor (I spent a while fighting ant and it is not
> >> a programming language, so not suitable for the decisions required for the
> >> multi-module recursive processing).
> > I'd favour dropping anything which is not working properly. ;-)
> >
> >> 3. The top level checkout is used in the release process for manually
> >> updating the site. But why all the others?
> > Indeed.
> > I just created (locally) empty "site-content" and never put anything in
> > them.  [Would be nice to automate; IIRC, Eric too had some mishaps
> > with "site-content"...]
> >
> >> If I go to for example commons-rng-client-api and empty the site-content
> >> folder ‘mvn clean package site’ still creates a site that looks fine.
> > Sure.
> > As you state above, why all the svn trickery appears in the POM is
> > a mistery...
>
> I have updated the rng parent pom to do a selective checkout of the site.
>
> Any child modules will just get an empty directory. The parent still
> gets the full checkout.
>
> I do not know if the full checkout is required.

IMO, it is not.

> It should at least be a
> svn versioned directory so that you can use it to copy a locally staged
> site back to the live site (as you describe above).

Sure, but I think that at setup (usually just after time the maven project
is "git clone"d), "site-content" in the top-level directory ("trunk") should
be initialized as "subversion" directory (using the info from the POM, I
guess) but without downloading the contents of the web site since a
developer will hardly ever need it (at least not until wanting to update
the live site).

> Since I do not fully understand what exactly is required of this
> directory I will leave it with the full checkout for now. This can
> always be changed by updating the 'prepare-checkout' execution in the
> 'setup-checkout' profile.

Does this behave as I propose above?

Also: I don't understand why the POM contains this sentence
  "This includes the legacy javadocs for commons-rng-examples release 1.0."

> >
> >> Another bug with multi-module builds is that the following reports are in
> >> each child module and are duplicates of that in the top level page:
> >>
> >> Project information
> >> - Team
> >> - SCM
> >> - Issue Management
> >> - Mailing lists
> >> - CI management
> >> - Distribution management
> > That's probably because, lacking sufficient knowledge, I copied everything
> > to each module (using the non-modular Commons Math as a template).
> > OTOH, I don't think that having the above in each "sub-site" is bad.
> I've left these.
> >
> >> Project reports
> >> - jira
> >>
> >> The ones in the project information menu are harmless and fast to create.
> >> The jira report takes a long time to generate. I think at least this one
> >> should be disabled in child modules.
> > +1
> > [The more so that it refers to all the issues, not only those that pertain
> > to the module at hand.]
>
> I've updated the jira report to filter on the component id. This must be
> keyworded in the Jira ticket. I will go through Jira and label those
> which are missing component labels.

Do you mean "component" or "module"?

If the former, I don't understand.
If the latter, I had rather suggested that the JIRA report is not split into
a separate list for each module; rationale being more or less that issues
management are is a project level task (directly impacting e.g. a release).
Similarly, the "RAT" and "Changes" reports should probably only be visible
at the top-level:
   http://commons.apache.org/proper/commons-rng/project-reports.html
while the "Checkstyle" one should only be visible in a module's "sub-site".

> Currently I have set examples to run a jira report using the 'examples'
> tag. This could be further sub-divisioned for each sub component of
> examples. Currently this is not done in Jira.
>
> >
> >> My motivation is to reduce bloat and and speed up the process of a site
> >> build. It was annoying when doing the release as you use clean checkouts and
> >> the download of 14 copies of the full site was slow.
> > Waiting for the upload is already painful enough: All files are transmitted at
> > each web site update because of some tag, or date, has changed. :-(
> >
> >>>> Since this process is repeated for every module it can get very slow. I
> >>>> changed the site checkout to copy the directory from the parent if it
> >>>> was present. There was no solution I could find to fix this to run in a
> >>>> single maven command as profile activation for all modules is done by
> >>>> the reactor before any work is performed. Thus if the parent does the
> >>>> checkout there is no way for all the child modules to know the parent
> >>>> checkout exists in their profiles: when the profiles are initialised the
> >>>> parent checkout may not exist.
> >>>>
> >>>> There may be a better way to do this but it is all done in an antrun
> >>>> plugin. Ant has limited if-else capability in the antrun plugin as it
> >>>> only allows 1 <target> tag per execution. You require multiple <target>
> >>>> tags in the same ant build to have conditional dependencies between
> >>>> them, i.e. check for parent folder checkout and copy, otherwise do a svn
> >>>> checkout.
> >>>>
> >>>> I am going to try moving all this to a build.xml file and call that. It
> >>>> should allow more powerful use of ant. It also separates the ant config
> >>>> from the maven config.
> >>>>
> >>>> If this works the build.xml for ant to checkout the site recursively
> >>>> could be put into a parent.
> >>>>
> >>>> I am still unclear on why this site checkout is required for all the
> >>>> child modules. It is used in the maven-scm-publish-plugin but that
> >>>> should be used on the top level module during a release process. So a
> >>>> simpler fix is to not checkout the site in all the children.
> >>>>
> >>>> A simple test would be to set the poms to not copy the directory for all
> >>>> the child modules and do a dummy release.
> >>>>
> >>>> It's a work in progress...
> >>> I'm lost; what's the purpose?
> >> Removing all these copies of the live site. I think I need to look at the
> >> code for the commons-release plugin to understand what this folder it used
> >> for. It seems to me that it is not used for general development.
> > Sure, as mentioned above, an existing but empty "site-content" and
> > everything works fine.
>
> The site build process should now be a bit faster and cleaner.
>

Thanks,
Gilles

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

Re: [RNG] Site layout for modular components (Was: Release [...] RNG [...])

[Alex Herbert <al...@gmail.com>]

On 14/11/2019 01:39, Gilles Sadowski wrote:
> 2019-11-14 1:35 UTC+01:00, Alex Herbert <al...@gmail.com>:
>>
>>> On 13 Nov 2019, at 23:53, Gilles Sadowski <gi...@gmail.com> wrote:
>>>
>>> Hello.
>>>
>>> Le mer. 13 nov. 2019 à 18:29, Alex Herbert <alex.d.herbert@gmail.com
>>> <ma...@gmail.com>> a écrit :
>>>>
>>>> On 13/11/2019 13:09, Gilles Sadowski wrote:
>>>>> Hi.
>>>>>
>>>>> Do you think that it would be feasible to have all those fixes applied
>>>>> to other modular components (that were based on the [RNG] layout)
>>>>> through a common layer (another POM) between those components
>>>>> and "commons-parent"?
>>>> Most of the fixes have been in the module site descriptors or items that
>>>> should be moved up to commons parent. It may be possible to put the site
>>>> descriptors into a parent. IIUC the site descriptors are merged together
>>>> before the maven site plugin creates the site. So the fix for the top
>>>> right banner could be moved into a common parent. Each child module
>>>> would also want to enumerate the past releases of the javadocs. Thus
>>>> they would require a site descriptor anyway and the banner fix would
>>>> only save 5 lines per site.xml for the banner.
>>> Well, I was thinking of whether a multi-layered POM could be more
>>> flexible and robust in handling the different type of components (e.g.
>>> "multi-module" or not).
>> I think this would take a bit more reading on exactly how Maven thinks a
>> multi-module project should work...
> Probably. :-/
>
>>>> I did a big change to the use of svn to checkout the current site. This
>>>> was required as the archived javadocs are not in a top level directory.
>>>> So each module has to be checked out, the archived javadocs set to be
>>>> excluded and then the rest of the site can be checked out.
>>> Sorry, I don't follow.
>>> Didn't links to the Javadoc of previous versions exist prior to those
>>> changes?
>> Yes. Take a look at the pom.xml on line 464 for prepare-checkout.
>>
>> This entire section was and is a mystery to me. I don’t know why it is
>> required to create a copy of the site locally.
> Oh, I seem to remember now that I was hit by this nonsense of
> svn checking out the web site when the "site-content" did not
> exist!
>
>> The previous code in this maven target was created on the assumption that it
>> was a single module project and the archived javadocs for every previous
>> version were in a javadocs directory under the top level directory. The same
>> code is present in lang, io, text, etc.
>>
>> The way it works for those projects is incorrect for a multi-module site as
>> the archived javadocs are in a different place. It also is a target run in
>> every module and so for a full site build with the examples modules you
>> ended up with 14 full checkout copies of the RNG site, including the old
>> archived javadocs.
> Not sure I get what you mean; but I don't think that anything related
> to svn should be necessary in the POM file, excerpt perhaps to automate
> the creation of an *empty* "site-content" directory (in every module)
> in order to prevent downloading the web site.
>
>> Anyway I fixed it to work as it should. It checks out the site and ignores
>> the old javadocs. I added a fix so child modules copy the parent site
>> checkout. This only works if invoked in two stages on a clean git checkout:
>>
>> mvn -N pre-site && mvn pre-site
>>
>> This in itself is annoying as you cannot do:
>>
>> git clone …
>> cd commons-rng && mvn site
>>
>> Without the checkout of the site in each module. I think I can fix this by
>> using an external ant build.xml file where you can do if-else logic. But I
>> was wondering if I even had to. Perhaps the goal only needs to run in the
>> parent, or the dist-archive module for a release.
> Not even there (IIUC whet you mean).
> What I do is something along the lines:
>   $ mvn site site:stage
>   $ cd site-content
>   $ rm -rf *
>   $ cd target/staging
>   $ cp -r . ../../site-content
> Then
>   $ cd ../../site-content
>   $ svn add ... the new files (shown with "?" by "svn status")
>   $ svn del ... the old files (shown with "!" by "svn status")
>   $ svn commit
>
>> What I would like to know is:
>>
>> 1. Do the child modules need this?
> I don't think so.
>
>> 2. What is it used for? If it is only for a release then it should be in the
>> release profile. Or maybe the commons-release plugin. Using ant to do this
>> external execution is just poor (I spent a while fighting ant and it is not
>> a programming language, so not suitable for the decisions required for the
>> multi-module recursive processing).
> I'd favour dropping anything which is not working properly. ;-)
>
>> 3. The top level checkout is used in the release process for manually
>> updating the site. But why all the others?
> Indeed.
> I just created (locally) empty "site-content" and never put anything in
> them.  [Would be nice to automate; IIRC, Eric too had some mishaps
> with "site-content"...]
>
>> If I go to for example commons-rng-client-api and empty the site-content
>> folder ‘mvn clean package site’ still creates a site that looks fine.
> Sure.
> As you state above, why all the svn trickery appears in the POM is
> a mistery...

I have updated the rng parent pom to do a selective checkout of the site.

Any child modules will just get an empty directory. The parent still 
gets the full checkout.

I do not know if the full checkout is required. It should at least be a 
svn versioned directory so that you can use it to copy a locally staged 
site back to the live site (as you describe above).

Since I do not fully understand what exactly is required of this 
directory I will leave it with the full checkout for now. This can 
always be changed by updating the 'prepare-checkout' execution in the 
'setup-checkout' profile.

>
>> Another bug with multi-module builds is that the following reports are in
>> each child module and are duplicates of that in the top level page:
>>
>> Project information
>> - Team
>> - SCM
>> - Issue Management
>> - Mailing lists
>> - CI management
>> - Distribution management
> That's probably because, lacking sufficient knowledge, I copied everything
> to each module (using the non-modular Commons Math as a template).
> OTOH, I don't think that having the above in each "sub-site" is bad.
I've left these.
>
>> Project reports
>> - jira
>>
>> The ones in the project information menu are harmless and fast to create.
>> The jira report takes a long time to generate. I think at least this one
>> should be disabled in child modules.
> +1
> [The more so that it refers to all the issues, not only those that pertain
> to the module at hand.]

I've updated the jira report to filter on the component id. This must be 
keyworded in the Jira ticket. I will go through Jira and label those 
which are missing component labels.

Currently I have set examples to run a jira report using the 'examples' 
tag. This could be further sub-divisioned for each sub component of 
examples. Currently this is not done in Jira.

>
>> My motivation is to reduce bloat and and speed up the process of a site
>> build. It was annoying when doing the release as you use clean checkouts and
>> the download of 14 copies of the full site was slow.
> Waiting for the upload is already painful enough: All files are transmitted at
> each web site update because of some tag, or date, has changed. :-(
>
>>>> Since this process is repeated for every module it can get very slow. I
>>>> changed the site checkout to copy the directory from the parent if it
>>>> was present. There was no solution I could find to fix this to run in a
>>>> single maven command as profile activation for all modules is done by
>>>> the reactor before any work is performed. Thus if the parent does the
>>>> checkout there is no way for all the child modules to know the parent
>>>> checkout exists in their profiles: when the profiles are initialised the
>>>> parent checkout may not exist.
>>>>
>>>> There may be a better way to do this but it is all done in an antrun
>>>> plugin. Ant has limited if-else capability in the antrun plugin as it
>>>> only allows 1 <target> tag per execution. You require multiple <target>
>>>> tags in the same ant build to have conditional dependencies between
>>>> them, i.e. check for parent folder checkout and copy, otherwise do a svn
>>>> checkout.
>>>>
>>>> I am going to try moving all this to a build.xml file and call that. It
>>>> should allow more powerful use of ant. It also separates the ant config
>>>> from the maven config.
>>>>
>>>> If this works the build.xml for ant to checkout the site recursively
>>>> could be put into a parent.
>>>>
>>>> I am still unclear on why this site checkout is required for all the
>>>> child modules. It is used in the maven-scm-publish-plugin but that
>>>> should be used on the top level module during a release process. So a
>>>> simpler fix is to not checkout the site in all the children.
>>>>
>>>> A simple test would be to set the poms to not copy the directory for all
>>>> the child modules and do a dummy release.
>>>>
>>>> It's a work in progress...
>>> I'm lost; what's the purpose?
>> Removing all these copies of the live site. I think I need to look at the
>> code for the commons-release plugin to understand what this folder it used
>> for. It seems to me that it is not used for general development.
> Sure, as mentioned above, an existing but empty "site-content" and
> everything works fine.

The site build process should now be a bit faster and cleaner.

Alex

>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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

Re: [RNG] Site layout for modular components (Was: Release [...] RNG [...])

[Gilles Sadowski <gi...@gmail.com>]

2019-11-14 1:35 UTC+01:00, Alex Herbert <al...@gmail.com>:
>
>
>> On 13 Nov 2019, at 23:53, Gilles Sadowski <gi...@gmail.com> wrote:
>>
>> Hello.
>>
>> Le mer. 13 nov. 2019 à 18:29, Alex Herbert <alex.d.herbert@gmail.com
>> <ma...@gmail.com>> a écrit :
>>>
>>>
>>> On 13/11/2019 13:09, Gilles Sadowski wrote:
>>>> Hi.
>>>>
>>>> Do you think that it would be feasible to have all those fixes applied
>>>> to other modular components (that were based on the [RNG] layout)
>>>> through a common layer (another POM) between those components
>>>> and "commons-parent"?
>>>
>>> Most of the fixes have been in the module site descriptors or items that
>>> should be moved up to commons parent. It may be possible to put the site
>>> descriptors into a parent. IIUC the site descriptors are merged together
>>> before the maven site plugin creates the site. So the fix for the top
>>> right banner could be moved into a common parent. Each child module
>>> would also want to enumerate the past releases of the javadocs. Thus
>>> they would require a site descriptor anyway and the banner fix would
>>> only save 5 lines per site.xml for the banner.
>>
>> Well, I was thinking of whether a multi-layered POM could be more
>> flexible and robust in handling the different type of components (e.g.
>> "multi-module" or not).
>
> I think this would take a bit more reading on exactly how Maven thinks a
> multi-module project should work...

Probably. :-/

>>
>>> I did a big change to the use of svn to checkout the current site. This
>>> was required as the archived javadocs are not in a top level directory.
>>> So each module has to be checked out, the archived javadocs set to be
>>> excluded and then the rest of the site can be checked out.
>>
>> Sorry, I don't follow.
>> Didn't links to the Javadoc of previous versions exist prior to those
>> changes?
>
> Yes. Take a look at the pom.xml on line 464 for prepare-checkout.
>
> This entire section was and is a mystery to me. I don’t know why it is
> required to create a copy of the site locally.

Oh, I seem to remember now that I was hit by this nonsense of
svn checking out the web site when the "site-content" did not
exist!

> The previous code in this maven target was created on the assumption that it
> was a single module project and the archived javadocs for every previous
> version were in a javadocs directory under the top level directory. The same
> code is present in lang, io, text, etc.
>
> The way it works for those projects is incorrect for a multi-module site as
> the archived javadocs are in a different place. It also is a target run in
> every module and so for a full site build with the examples modules you
> ended up with 14 full checkout copies of the RNG site, including the old
> archived javadocs.

Not sure I get what you mean; but I don't think that anything related
to svn should be necessary in the POM file, excerpt perhaps to automate
the creation of an *empty* "site-content" directory (in every module)
in order to prevent downloading the web site.

>
> Anyway I fixed it to work as it should. It checks out the site and ignores
> the old javadocs. I added a fix so child modules copy the parent site
> checkout. This only works if invoked in two stages on a clean git checkout:
>
> mvn -N pre-site && mvn pre-site
>
> This in itself is annoying as you cannot do:
>
> git clone …
> cd commons-rng && mvn site
>
> Without the checkout of the site in each module. I think I can fix this by
> using an external ant build.xml file where you can do if-else logic. But I
> was wondering if I even had to. Perhaps the goal only needs to run in the
> parent, or the dist-archive module for a release.

Not even there (IIUC whet you mean).
What I do is something along the lines:
 $ mvn site site:stage
 $ cd site-content
 $ rm -rf *
 $ cd target/staging
 $ cp -r . ../../site-content
Then
 $ cd ../../site-content
 $ svn add ... the new files (shown with "?" by "svn status")
 $ svn del ... the old files (shown with "!" by "svn status")
 $ svn commit

>
> What I would like to know is:
>
> 1. Do the child modules need this?

I don't think so.

> 2. What is it used for? If it is only for a release then it should be in the
> release profile. Or maybe the commons-release plugin. Using ant to do this
> external execution is just poor (I spent a while fighting ant and it is not
> a programming language, so not suitable for the decisions required for the
> multi-module recursive processing).

I'd favour dropping anything which is not working properly. ;-)

> 3. The top level checkout is used in the release process for manually
> updating the site. But why all the others?

Indeed.
I just created (locally) empty "site-content" and never put anything in
them.  [Would be nice to automate; IIRC, Eric too had some mishaps
with "site-content"...]

>
> If I go to for example commons-rng-client-api and empty the site-content
> folder ‘mvn clean package site’ still creates a site that looks fine.

Sure.
As you state above, why all the svn trickery appears in the POM is
a mistery...

>
> Another bug with multi-module builds is that the following reports are in
> each child module and are duplicates of that in the top level page:
>
> Project information
> - Team
> - SCM
> - Issue Management
> - Mailing lists
> - CI management
> - Distribution management

That's probably because, lacking sufficient knowledge, I copied everything
to each module (using the non-modular Commons Math as a template).
OTOH, I don't think that having the above in each "sub-site" is bad.

> Project reports
> - jira
>
> The ones in the project information menu are harmless and fast to create.
> The jira report takes a long time to generate. I think at least this one
> should be disabled in child modules.

+1
[The more so that it refers to all the issues, not only those that pertain
to the module at hand.]

>
> My motivation is to reduce bloat and and speed up the process of a site
> build. It was annoying when doing the release as you use clean checkouts and
> the download of 14 copies of the full site was slow.

Waiting for the upload is already painful enough: All files are transmitted at
each web site update because of some tag, or date, has changed. :-(

>>>
>>> Since this process is repeated for every module it can get very slow. I
>>> changed the site checkout to copy the directory from the parent if it
>>> was present. There was no solution I could find to fix this to run in a
>>> single maven command as profile activation for all modules is done by
>>> the reactor before any work is performed. Thus if the parent does the
>>> checkout there is no way for all the child modules to know the parent
>>> checkout exists in their profiles: when the profiles are initialised the
>>> parent checkout may not exist.
>>>
>>> There may be a better way to do this but it is all done in an antrun
>>> plugin. Ant has limited if-else capability in the antrun plugin as it
>>> only allows 1 <target> tag per execution. You require multiple <target>
>>> tags in the same ant build to have conditional dependencies between
>>> them, i.e. check for parent folder checkout and copy, otherwise do a svn
>>> checkout.
>>>
>>> I am going to try moving all this to a build.xml file and call that. It
>>> should allow more powerful use of ant. It also separates the ant config
>>> from the maven config.
>>>
>>> If this works the build.xml for ant to checkout the site recursively
>>> could be put into a parent.
>>>
>>> I am still unclear on why this site checkout is required for all the
>>> child modules. It is used in the maven-scm-publish-plugin but that
>>> should be used on the top level module during a release process. So a
>>> simpler fix is to not checkout the site in all the children.
>>>
>>> A simple test would be to set the poms to not copy the directory for all
>>> the child modules and do a dummy release.
>>>
>>> It's a work in progress...
>>
>> I'm lost; what's the purpose?
>
> Removing all these copies of the live site. I think I need to look at the
> code for the commons-release plugin to understand what this folder it used
> for. It seems to me that it is not used for general development.

Sure, as mentioned above, an existing but empty "site-content" and
everything works fine.

Regards,
Gilles

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

Re: [RNG] Site layout for modular components (Was: Release [...] RNG [...])

[Alex Herbert <al...@gmail.com>]

> On 13 Nov 2019, at 23:53, Gilles Sadowski <gi...@gmail.com> wrote:
> 
> Hello.
> 
> Le mer. 13 nov. 2019 à 18:29, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
>> 
>> 
>> On 13/11/2019 13:09, Gilles Sadowski wrote:
>>> Hi.
>>> 
>>> Do you think that it would be feasible to have all those fixes applied
>>> to other modular components (that were based on the [RNG] layout)
>>> through a common layer (another POM) between those components
>>> and "commons-parent"?
>> 
>> Most of the fixes have been in the module site descriptors or items that
>> should be moved up to commons parent. It may be possible to put the site
>> descriptors into a parent. IIUC the site descriptors are merged together
>> before the maven site plugin creates the site. So the fix for the top
>> right banner could be moved into a common parent. Each child module
>> would also want to enumerate the past releases of the javadocs. Thus
>> they would require a site descriptor anyway and the banner fix would
>> only save 5 lines per site.xml for the banner.
> 
> Well, I was thinking of whether a multi-layered POM could be more
> flexible and robust in handling the different type of components (e.g.
> "multi-module" or not).

I think this would take a bit more reading on exactly how Maven thinks a multi-module project should work...

> 
>> I did a big change to the use of svn to checkout the current site. This
>> was required as the archived javadocs are not in a top level directory.
>> So each module has to be checked out, the archived javadocs set to be
>> excluded and then the rest of the site can be checked out.
> 
> Sorry, I don't follow.
> Didn't links to the Javadoc of previous versions exist prior to those
> changes?

Yes. Take a look at the pom.xml on line 464 for prepare-checkout.

This entire section was and is a mystery to me. I don’t know why it is required to create a copy of the site locally. 

The previous code in this maven target was created on the assumption that it was a single module project and the archived javadocs for every previous version were in a javadocs directory under the top level directory. The same code is present in lang, io, text, etc.

The way it works for those projects is incorrect for a multi-module site as the archived javadocs are in a different place. It also is a target run in every module and so for a full site build with the examples modules you ended up with 14 full checkout copies of the RNG site, including the old archived javadocs.

Anyway I fixed it to work as it should. It checks out the site and ignores the old javadocs. I added a fix so child modules copy the parent site checkout. This only works if invoked in two stages on a clean git checkout:

mvn -N pre-site && mvn pre-site

This in itself is annoying as you cannot do:

git clone …
cd commons-rng && mvn site

Without the checkout of the site in each module. I think I can fix this by using an external ant build.xml file where you can do if-else logic. But I was wondering if I even had to. Perhaps the goal only needs to run in the parent, or the dist-archive module for a release.

What I would like to know is:

1. Do the child modules need this?
2. What is it used for? If it is only for a release then it should be in the release profile. Or maybe the commons-release plugin. Using ant to do this external execution is just poor (I spent a while fighting ant and it is not a programming language, so not suitable for the decisions required for the multi-module recursive processing).
3. The top level checkout is used in the release process for manually updating the site. But why all the others?

If I go to for example commons-rng-client-api and empty the site-content folder ‘mvn clean package site’ still creates a site that looks fine.

Another bug with multi-module builds is that the following reports are in each child module and are duplicates of that in the top level page:

Project information
- Team
- SCM
- Issue Management
- Mailing lists
- CI management
- Distribution management

Project reports
- jira

The ones in the project information menu are harmless and fast to create. The jira report takes a long time to generate. I think at least this one should be disabled in child modules.

My motivation is to reduce bloat and and speed up the process of a site build. It was annoying when doing the release as you use clean checkouts and the download of 14 copies of the full site was slow.

> 
>> 
>> Since this process is repeated for every module it can get very slow. I
>> changed the site checkout to copy the directory from the parent if it
>> was present. There was no solution I could find to fix this to run in a
>> single maven command as profile activation for all modules is done by
>> the reactor before any work is performed. Thus if the parent does the
>> checkout there is no way for all the child modules to know the parent
>> checkout exists in their profiles: when the profiles are initialised the
>> parent checkout may not exist.
>> 
>> There may be a better way to do this but it is all done in an antrun
>> plugin. Ant has limited if-else capability in the antrun plugin as it
>> only allows 1 <target> tag per execution. You require multiple <target>
>> tags in the same ant build to have conditional dependencies between
>> them, i.e. check for parent folder checkout and copy, otherwise do a svn
>> checkout.
>> 
>> I am going to try moving all this to a build.xml file and call that. It
>> should allow more powerful use of ant. It also separates the ant config
>> from the maven config.
>> 
>> If this works the build.xml for ant to checkout the site recursively
>> could be put into a parent.
>> 
>> I am still unclear on why this site checkout is required for all the
>> child modules. It is used in the maven-scm-publish-plugin but that
>> should be used on the top level module during a release process. So a
>> simpler fix is to not checkout the site in all the children.
>> 
>> A simple test would be to set the poms to not copy the directory for all
>> the child modules and do a dummy release.
>> 
>> It's a work in progress...
> 
> I'm lost; what's the purpose?

Removing all these copies of the live site. I think I need to look at the code for the commons-release plugin to understand what this folder it used for. It seems to me that it is not used for general development.

> 
> Gilles
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>

Re: [RNG] Site layout for modular components (Was: Release [...] RNG [...])

[Gilles Sadowski <gi...@gmail.com>]

Hello.

Le mer. 13 nov. 2019 à 18:29, Alex Herbert <al...@gmail.com> a écrit :
>
>
> On 13/11/2019 13:09, Gilles Sadowski wrote:
> > Hi.
> >
> > Do you think that it would be feasible to have all those fixes applied
> > to other modular components (that were based on the [RNG] layout)
> > through a common layer (another POM) between those components
> > and "commons-parent"?
>
> Most of the fixes have been in the module site descriptors or items that
> should be moved up to commons parent. It may be possible to put the site
> descriptors into a parent. IIUC the site descriptors are merged together
> before the maven site plugin creates the site. So the fix for the top
> right banner could be moved into a common parent. Each child module
> would also want to enumerate the past releases of the javadocs. Thus
> they would require a site descriptor anyway and the banner fix would
> only save 5 lines per site.xml for the banner.

Well, I was thinking of whether a multi-layered POM could be more
flexible and robust in handling the different type of components (e.g.
"multi-module" or not).

> I did a big change to the use of svn to checkout the current site. This
> was required as the archived javadocs are not in a top level directory.
> So each module has to be checked out, the archived javadocs set to be
> excluded and then the rest of the site can be checked out.

Sorry, I don't follow.
Didn't links to the Javadoc of previous versions exist prior to those
changes?

>
> Since this process is repeated for every module it can get very slow. I
> changed the site checkout to copy the directory from the parent if it
> was present. There was no solution I could find to fix this to run in a
> single maven command as profile activation for all modules is done by
> the reactor before any work is performed. Thus if the parent does the
> checkout there is no way for all the child modules to know the parent
> checkout exists in their profiles: when the profiles are initialised the
> parent checkout may not exist.
>
> There may be a better way to do this but it is all done in an antrun
> plugin. Ant has limited if-else capability in the antrun plugin as it
> only allows 1 <target> tag per execution. You require multiple <target>
> tags in the same ant build to have conditional dependencies between
> them, i.e. check for parent folder checkout and copy, otherwise do a svn
> checkout.
>
> I am going to try moving all this to a build.xml file and call that. It
> should allow more powerful use of ant. It also separates the ant config
> from the maven config.
>
> If this works the build.xml for ant to checkout the site recursively
> could be put into a parent.
>
> I am still unclear on why this site checkout is required for all the
> child modules. It is used in the maven-scm-publish-plugin but that
> should be used on the top level module during a release process. So a
> simpler fix is to not checkout the site in all the children.
>
> A simple test would be to set the poms to not copy the directory for all
> the child modules and do a dummy release.
>
> It's a work in progress...

I'm lost; what's the purpose?

Gilles

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

Re: [RNG] Site layout for modular components (Was: Release [...] RNG [...])

[Alex Herbert <al...@gmail.com>]

On 13/11/2019 13:09, Gilles Sadowski wrote:
> Hi.
>
> Do you think that it would be feasible to have all those fixes applied
> to other modular components (that were based on the [RNG] layout)
> through a common layer (another POM) between those components
> and "commons-parent"?

Most of the fixes have been in the module site descriptors or items that 
should be moved up to commons parent. It may be possible to put the site 
descriptors into a parent. IIUC the site descriptors are merged together 
before the maven site plugin creates the site. So the fix for the top 
right banner could be moved into a common parent. Each child module 
would also want to enumerate the past releases of the javadocs. Thus 
they would require a site descriptor anyway and the banner fix would 
only save 5 lines per site.xml for the banner.


I did a big change to the use of svn to checkout the current site. This 
was required as the archived javadocs are not in a top level directory. 
So each module has to be checked out, the archived javadocs set to be 
excluded and then the rest of the site can be checked out.

Since this process is repeated for every module it can get very slow. I 
changed the site checkout to copy the directory from the parent if it 
was present. There was no solution I could find to fix this to run in a 
single maven command as profile activation for all modules is done by 
the reactor before any work is performed. Thus if the parent does the 
checkout there is no way for all the child modules to know the parent 
checkout exists in their profiles: when the profiles are initialised the 
parent checkout may not exist.

There may be a better way to do this but it is all done in an antrun 
plugin. Ant has limited if-else capability in the antrun plugin as it 
only allows 1 <target> tag per execution. You require multiple <target> 
tags in the same ant build to have conditional dependencies between 
them, i.e. check for parent folder checkout and copy, otherwise do a svn 
checkout.

I am going to try moving all this to a build.xml file and call that. It 
should allow more powerful use of ant. It also separates the ant config 
from the maven config.

If this works the build.xml for ant to checkout the site recursively 
could be put into a parent.

I am still unclear on why this site checkout is required for all the 
child modules. It is used in the maven-scm-publish-plugin but that 
should be used on the top level module during a release process. So a 
simpler fix is to not checkout the site in all the children.

A simple test would be to set the poms to not copy the directory for all 
the child modules and do a dummy release.

It's a work in progress...


>
> Regards,
> Gilles
>
> Le mer. 13 nov. 2019 à 12:53, Alex Herbert <al...@gmail.com> a écrit :
>> [...]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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

[RNG] Site layout for modular components (Was: Release [...] RNG [...])

[Gilles Sadowski <gi...@gmail.com>]

Hi.

Do you think that it would be feasible to have all those fixes applied
to other modular components (that were based on the [RNG] layout)
through a common layer (another POM) between those components
and "commons-parent"?

Regards,
Gilles

Le mer. 13 nov. 2019 à 12:53, Alex Herbert <al...@gmail.com> a écrit :
>
> [...]

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

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

[Alex Herbert <al...@gmail.com>]

On 13/11/2019 11:38, Gilles Sadowski wrote:
> Hello.
>
> Le mar. 12 nov. 2019 à 17:41, Alex Herbert <al...@gmail.com> a écrit :
>>
>>
>>> On 12 Nov 2019, at 15:39, Gilles Sadowski <gi...@gmail.com> wrote:
>>>
>>> Hello Alex.
>>>
>>> Le mar. 12 nov. 2019 à 16:15, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
>>>>
>>>> On 12/11/2019 09:06, Gilles Sadowski wrote:
>>>>> 2019-11-12 2:28 UTC+01:00, Alex Herbert <al...@gmail.com>:
>>>>>>> On 11 Nov 2019, at 23:40, Gilles Sadowski <gi...@gmail.com> wrote:
>>>>>>>
>>>>>>> Hi.
>>>>>>>
>>>>>>> Maybe I'm missing what the issues really are,
>>>>>> All empty japicmp reports on the site.
>>>>>> Some confusing empty Jacoco aggregate reports on the site.
>>>>>>
>>>>>>> so sorry if this top-posted
>>>>>>> reply is beside the points:
>>>>>>> 1. There always have been several issues with JapiCmp (I do not remember
>>>>>>> exactly which; it must be in the ML archive); it never worked with
>>>>>>> Commons
>>>>>>> RNG.  [As as been mentioned in some thread and on JIRA, it might be worth
>>>>>>> spending time (if any) setting up the tools provided by the "revapi"
>>>>>>> project.]
>>>>>>> For now, Clirr still works fine for [RNG] (IIUC because of its "old" JDK
>>>>>>> target)
>>>>>>> and there is no need to have JapiCmp.
>>>>>> I’ve got japicmp to work in master. Maybe old versions had problems that
>>>>>> have now been fixed.
>>>>> I seem to remember that it failed the build for release 1.0 because there
>>>>> was no version to compare with (and it couldn't be prevented to run using
>>>>> the CP setup - cf. below).
>>>> Looking at the documentation I think this problem has been fixed with
>>>> optional properties. The appropriate property is not used in CP but a
>>>> project could just set it to true and the build would not fail.
>>>>
>>>>>> I think commons-parent should not be setup to generated empty reports when
>>>>>> it is not included as a profile.
>>>>> +1
>>>>> That was one of the issue.  Such plugins are optionally activated by the
>>>>> presence of a file, and should not run if the file is not present.  The setup
>>>>> works for other tools but it didn't for JapiCmp.
>>>>>
>>>>>>> 2. IMHO, there is no need for Jacoco aggregate reports; each module has
>>>>>>> its
>>>>>>> own "plain" report, accessible under the module's "sub-site" along with
>>>>>>> all
>>>>>>> the other reports concerned with that particular body of code.  If
>>>>>>> designed
>>>>>>> correctly (and in order to work under JPMS), the modules must have
>>>>>>> acyclic dependencies, and it seems to me equally meaningless to have
>>>>>>> modules
>>>>>>> aggregate reports as to have aggregate reports of external dependencies.
>>>>>> +1.
>>>>>>
>>>>>> I’ve disabled the aggregate report in RNG. I think it should be disabled in
>>>>>> commons-parent.
>>>>> + 1
>>>>> AFAICT, the latest CP enhanced automation does not take into account
>>>>> the "multi-module" maven feature.
>>>>> I had raised the question of why a "dist-archive" module is necessary:
>>>>> It seems to me that all the info being in the modules, the main POM
>>>>> should be able to generate, collect and "archive" all the artefacts under
>>>>> its own "target" directory.
>>>>> I've never dug very deep into maven, so I don't how whether it's possible
>>>>> or whether it's indeed to be done the (contorted, IMHO) way it is now.
>>>> I've tried to update RNG to work with japicmp conditionally.
>>>> Unfortunately once the maven plugin is included there is no way to
>>>> totally disable it. It will always put up an empty report in the site
>>>> generation.
>>>>
>>>> The fix was to locally change CP 49 (which RNG depends on) to move all
>>>> the configuration inside the profile that is activated using the file
>>>> 'src/site/resources/profile.japicmp'.
>>>>
>>>> A first fix with this present broke the RNG build on pre-Java8 JDKs. The
>>>> profile activation should also include activation if the JDK is 1.8+:
>>>>
>>>>        <activation>
>>>>          <jdk>[1.8,)</jdk>
>>>>          <file>
>>>> <exists>src/site/resources/profile.japicmp</exists>
>>>>          </file>
>>>>        </activation>
>>>>
>>>> I've rebuilt the report pages of the site using this set-up (fixed RNG,
>>>> fudged CP 49 locally). The JaCoCo aggregates are gone and the japicmp
>>>> reports are gone for all but:
>>>>
>>>> https://commons.apache.org/proper/commons-rng/commons-rng-client-api/japicmp.html
>>>>
>>>> https://commons.apache.org/proper/commons-rng/commons-rng-core/japicmp.html
>>>>
>>>> https://commons.apache.org/proper/commons-rng/commons-rng-simple/japicmp.html
>>>>
>>>> https://commons.apache.org/proper/commons-rng/commons-rng-sampling/japicmp.html
>>>>
>>>>
>>>> To fix the RNG build so that it can optionally include japicmp in the
>>>> report menus will require a change to the parent.
>>>>
>>>> However some projects may not be using
>>>> 'src/site/resources/profile.japicmp' to activate the profile. They may
>>>> be directly using <japicmp.skip>false</japicmp.skip>.
>>>>
>>>> So how to proceed with a fix for CP?
>>> If you found a fix, please apply it to CP and "release" v50.
>>> If there are issues, they will be fixed in 51+.
>> Q. Should this be run by the dev mailing list under the prefix [parent]?
> Or [CP] or maybe [All].
> Wouldn't hurt.

I have made changes to CP for jacoco and japicmp. They seem to be 
non-destructive.

I am trying a fix to enable MathJax. It involves updating commons-skin 
(last release in 2015) as that is where the header is set for all site 
pages.

>
>> Looking at the site for the modules the top right icon is missing, e.g.
>>
>> https://commons.apache.org/proper/commons-rng/commons-rng-core/index.html <https://commons.apache.org/proper/commons-rng/commons-rng-core/index.html>
>>
>> It comes from ’src/site/site.xml’
>>
>> For all the modules this still requires images/commons_rng.small.png, which is missing.
>>
>> So:
>>
>> - Duplicate this image through the entire hierarchy
>> - Fix it to refer to the official image: https://commons.apache.org/proper/commons-rng/images/commons_rng.small.png <https://commons.apache.org/proper/commons-rng/images/commons_rng.small.png>
> +1 (the latter)
> [I've seen that it's done already.]

Yes. The maven site plugin tries to relativize absolute URLs that point 
to the deploy site URL. So I've used this feature in the site.xml and 
now the banner is fixed everywhere.

I still have to figure out how to post process the user guide (rng.apt) 
to update the <pre> tags generated by doxia to <pre "prettyprint">. I 
did this on the manually written pages and now code is rendered with 
highlighting, e.g.

https://commons.apache.org/proper/commons-rng/commons-rng-simple/index.html

>
>> The link could also be made non-relative: https://commons.apache.org/proper/commons-rng/ <https://commons.apache.org/proper/commons-rng/>
>>
>> This would allow you to get back to the top level page from any of the modules pages. I don’t think this is possible at the moment.
> +1
>
> Thanks,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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

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

[Gilles Sadowski <gi...@gmail.com>]

Hello.

Le mar. 12 nov. 2019 à 17:41, Alex Herbert <al...@gmail.com> a écrit :
>
>
>
> > On 12 Nov 2019, at 15:39, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Hello Alex.
> >
> > Le mar. 12 nov. 2019 à 16:15, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
> >>
> >>
> >> On 12/11/2019 09:06, Gilles Sadowski wrote:
> >>> 2019-11-12 2:28 UTC+01:00, Alex Herbert <al...@gmail.com>:
> >>>>
> >>>>> On 11 Nov 2019, at 23:40, Gilles Sadowski <gi...@gmail.com> wrote:
> >>>>>
> >>>>> Hi.
> >>>>>
> >>>>> Maybe I'm missing what the issues really are,
> >>>> All empty japicmp reports on the site.
> >>>> Some confusing empty Jacoco aggregate reports on the site.
> >>>>
> >>>>> so sorry if this top-posted
> >>>>> reply is beside the points:
> >>>>> 1. There always have been several issues with JapiCmp (I do not remember
> >>>>> exactly which; it must be in the ML archive); it never worked with
> >>>>> Commons
> >>>>> RNG.  [As as been mentioned in some thread and on JIRA, it might be worth
> >>>>> spending time (if any) setting up the tools provided by the "revapi"
> >>>>> project.]
> >>>>> For now, Clirr still works fine for [RNG] (IIUC because of its "old" JDK
> >>>>> target)
> >>>>> and there is no need to have JapiCmp.
> >>>> I’ve got japicmp to work in master. Maybe old versions had problems that
> >>>> have now been fixed.
> >>> I seem to remember that it failed the build for release 1.0 because there
> >>> was no version to compare with (and it couldn't be prevented to run using
> >>> the CP setup - cf. below).
> >>
> >> Looking at the documentation I think this problem has been fixed with
> >> optional properties. The appropriate property is not used in CP but a
> >> project could just set it to true and the build would not fail.
> >>
> >>>
> >>>> I think commons-parent should not be setup to generated empty reports when
> >>>> it is not included as a profile.
> >>> +1
> >>> That was one of the issue.  Such plugins are optionally activated by the
> >>> presence of a file, and should not run if the file is not present.  The setup
> >>> works for other tools but it didn't for JapiCmp.
> >>>
> >>>>> 2. IMHO, there is no need for Jacoco aggregate reports; each module has
> >>>>> its
> >>>>> own "plain" report, accessible under the module's "sub-site" along with
> >>>>> all
> >>>>> the other reports concerned with that particular body of code.  If
> >>>>> designed
> >>>>> correctly (and in order to work under JPMS), the modules must have
> >>>>> acyclic dependencies, and it seems to me equally meaningless to have
> >>>>> modules
> >>>>> aggregate reports as to have aggregate reports of external dependencies.
> >>>> +1.
> >>>>
> >>>> I’ve disabled the aggregate report in RNG. I think it should be disabled in
> >>>> commons-parent.
> >>> + 1
> >>> AFAICT, the latest CP enhanced automation does not take into account
> >>> the "multi-module" maven feature.
> >>> I had raised the question of why a "dist-archive" module is necessary:
> >>> It seems to me that all the info being in the modules, the main POM
> >>> should be able to generate, collect and "archive" all the artefacts under
> >>> its own "target" directory.
> >>> I've never dug very deep into maven, so I don't how whether it's possible
> >>> or whether it's indeed to be done the (contorted, IMHO) way it is now.
> >>
> >> I've tried to update RNG to work with japicmp conditionally.
> >> Unfortunately once the maven plugin is included there is no way to
> >> totally disable it. It will always put up an empty report in the site
> >> generation.
> >>
> >> The fix was to locally change CP 49 (which RNG depends on) to move all
> >> the configuration inside the profile that is activated using the file
> >> 'src/site/resources/profile.japicmp'.
> >>
> >> A first fix with this present broke the RNG build on pre-Java8 JDKs. The
> >> profile activation should also include activation if the JDK is 1.8+:
> >>
> >>       <activation>
> >>         <jdk>[1.8,)</jdk>
> >>         <file>
> >> <exists>src/site/resources/profile.japicmp</exists>
> >>         </file>
> >>       </activation>
> >>
> >> I've rebuilt the report pages of the site using this set-up (fixed RNG,
> >> fudged CP 49 locally). The JaCoCo aggregates are gone and the japicmp
> >> reports are gone for all but:
> >>
> >> https://commons.apache.org/proper/commons-rng/commons-rng-client-api/japicmp.html
> >>
> >> https://commons.apache.org/proper/commons-rng/commons-rng-core/japicmp.html
> >>
> >> https://commons.apache.org/proper/commons-rng/commons-rng-simple/japicmp.html
> >>
> >> https://commons.apache.org/proper/commons-rng/commons-rng-sampling/japicmp.html
> >>
> >>
> >> To fix the RNG build so that it can optionally include japicmp in the
> >> report menus will require a change to the parent.
> >>
> >> However some projects may not be using
> >> 'src/site/resources/profile.japicmp' to activate the profile. They may
> >> be directly using <japicmp.skip>false</japicmp.skip>.
> >>
> >> So how to proceed with a fix for CP?
> >
> > If you found a fix, please apply it to CP and "release" v50.
> > If there are issues, they will be fixed in 51+.
>
> Q. Should this be run by the dev mailing list under the prefix [parent]?

Or [CP] or maybe [All].
Wouldn't hurt.

>
> Looking at the site for the modules the top right icon is missing, e.g.
>
> https://commons.apache.org/proper/commons-rng/commons-rng-core/index.html <https://commons.apache.org/proper/commons-rng/commons-rng-core/index.html>
>
> It comes from ’src/site/site.xml’
>
> For all the modules this still requires images/commons_rng.small.png, which is missing.
>
> So:
>
> - Duplicate this image through the entire hierarchy
> - Fix it to refer to the official image: https://commons.apache.org/proper/commons-rng/images/commons_rng.small.png <https://commons.apache.org/proper/commons-rng/images/commons_rng.small.png>

+1 (the latter)
[I've seen that it's done already.]

> The link could also be made non-relative: https://commons.apache.org/proper/commons-rng/ <https://commons.apache.org/proper/commons-rng/>
>
> This would allow you to get back to the top level page from any of the modules pages. I don’t think this is possible at the moment.

+1

Thanks,
Gilles

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

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

[Alex Herbert <al...@gmail.com>]

> On 12 Nov 2019, at 16:41, Alex Herbert <al...@gmail.com> wrote:
> 
> 
> 
>> On 12 Nov 2019, at 15:39, Gilles Sadowski <gilleseran@gmail.com <ma...@gmail.com>> wrote:
>> 
>> Hello Alex.
>> 
>> Le mar. 12 nov. 2019 à 16:15, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
>>> 
>>> 
>>> On 12/11/2019 09:06, Gilles Sadowski wrote:
>>>> 2019-11-12 2:28 UTC+01:00, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>>:
>>>>> 
>>>>>> On 11 Nov 2019, at 23:40, Gilles Sadowski <gilleseran@gmail.com <ma...@gmail.com>> wrote:
>>>>>> 
>>>>>> Hi.
>>>>>> 
>>>>>> Maybe I'm missing what the issues really are,
>>>>> All empty japicmp reports on the site.
>>>>> Some confusing empty Jacoco aggregate reports on the site.
>>>>> 
>>>>>> so sorry if this top-posted
>>>>>> reply is beside the points:
>>>>>> 1. There always have been several issues with JapiCmp (I do not remember
>>>>>> exactly which; it must be in the ML archive); it never worked with
>>>>>> Commons
>>>>>> RNG.  [As as been mentioned in some thread and on JIRA, it might be worth
>>>>>> spending time (if any) setting up the tools provided by the "revapi"
>>>>>> project.]
>>>>>> For now, Clirr still works fine for [RNG] (IIUC because of its "old" JDK
>>>>>> target)
>>>>>> and there is no need to have JapiCmp.
>>>>> I’ve got japicmp to work in master. Maybe old versions had problems that
>>>>> have now been fixed.
>>>> I seem to remember that it failed the build for release 1.0 because there
>>>> was no version to compare with (and it couldn't be prevented to run using
>>>> the CP setup - cf. below).
>>> 
>>> Looking at the documentation I think this problem has been fixed with
>>> optional properties. The appropriate property is not used in CP but a
>>> project could just set it to true and the build would not fail.
>>> 
>>>> 
>>>>> I think commons-parent should not be setup to generated empty reports when
>>>>> it is not included as a profile.
>>>> +1
>>>> That was one of the issue.  Such plugins are optionally activated by the
>>>> presence of a file, and should not run if the file is not present.  The setup
>>>> works for other tools but it didn't for JapiCmp.
>>>> 
>>>>>> 2. IMHO, there is no need for Jacoco aggregate reports; each module has
>>>>>> its
>>>>>> own "plain" report, accessible under the module's "sub-site" along with
>>>>>> all
>>>>>> the other reports concerned with that particular body of code.  If
>>>>>> designed
>>>>>> correctly (and in order to work under JPMS), the modules must have
>>>>>> acyclic dependencies, and it seems to me equally meaningless to have
>>>>>> modules
>>>>>> aggregate reports as to have aggregate reports of external dependencies.
>>>>> +1.
>>>>> 
>>>>> I’ve disabled the aggregate report in RNG. I think it should be disabled in
>>>>> commons-parent.
>>>> + 1
>>>> AFAICT, the latest CP enhanced automation does not take into account
>>>> the "multi-module" maven feature.
>>>> I had raised the question of why a "dist-archive" module is necessary:
>>>> It seems to me that all the info being in the modules, the main POM
>>>> should be able to generate, collect and "archive" all the artefacts under
>>>> its own "target" directory.
>>>> I've never dug very deep into maven, so I don't how whether it's possible
>>>> or whether it's indeed to be done the (contorted, IMHO) way it is now.
>>> 
>>> I've tried to update RNG to work with japicmp conditionally.
>>> Unfortunately once the maven plugin is included there is no way to
>>> totally disable it. It will always put up an empty report in the site
>>> generation.
>>> 
>>> The fix was to locally change CP 49 (which RNG depends on) to move all
>>> the configuration inside the profile that is activated using the file
>>> 'src/site/resources/profile.japicmp'.
>>> 
>>> A first fix with this present broke the RNG build on pre-Java8 JDKs. The
>>> profile activation should also include activation if the JDK is 1.8+:
>>> 
>>>       <activation>
>>>         <jdk>[1.8,)</jdk>
>>>         <file>
>>> <exists>src/site/resources/profile.japicmp</exists>
>>>         </file>
>>>       </activation>
>>> 
>>> I've rebuilt the report pages of the site using this set-up (fixed RNG,
>>> fudged CP 49 locally). The JaCoCo aggregates are gone and the japicmp
>>> reports are gone for all but:
>>> 
>>> https://commons.apache.org/proper/commons-rng/commons-rng-client-api/japicmp.html <https://commons.apache.org/proper/commons-rng/commons-rng-client-api/japicmp.html>
>>> 
>>> https://commons.apache.org/proper/commons-rng/commons-rng-core/japicmp.html
>>> 
>>> https://commons.apache.org/proper/commons-rng/commons-rng-simple/japicmp.html
>>> 
>>> https://commons.apache.org/proper/commons-rng/commons-rng-sampling/japicmp.html
>>> 
>>> 
>>> To fix the RNG build so that it can optionally include japicmp in the
>>> report menus will require a change to the parent.
>>> 
>>> However some projects may not be using
>>> 'src/site/resources/profile.japicmp' to activate the profile. They may
>>> be directly using <japicmp.skip>false</japicmp.skip>.
>>> 
>>> So how to proceed with a fix for CP?
>> 
>> If you found a fix, please apply it to CP and "release" v50.
>> If there are issues, they will be fixed in 51+.
> 
> Q. Should this be run by the dev mailing list under the prefix [parent]?
> 
> 
> 
> Looking at the site for the modules the top right icon is missing, e.g.
> 
> https://commons.apache.org/proper/commons-rng/commons-rng-core/index.html <https://commons.apache.org/proper/commons-rng/commons-rng-core/index.html>
> 
> It comes from ’src/site/site.xml’
> 
> For all the modules this still requires images/commons_rng.small.png, which is missing.
> 
> So:
> 
> - Duplicate this image through the entire hierarchy
> - Fix it to refer to the official image: https://commons.apache.org/proper/commons-rng/images/commons_rng.small.png <https://commons.apache.org/proper/commons-rng/images/commons_rng.small.png>
> 
> The link could also be made non-relative: https://commons.apache.org/proper/commons-rng/ <https://commons.apache.org/proper/commons-rng/>
> 
> This would allow you to get back to the top level page from any of the modules pages. I don’t think this is possible at the moment.

Oh dear. I found that the modules have a 'src/site/site.xml’ too. This was not in clear in the release how.to and I missed updating it.

The examples modules do not have a different site.xml and the logo is fine and it links back to the main top level page.

I’ll update the site xml files for each of the modules to:

- have the correct javadoc links
- have the logo in the corner
- link back to the top level page

Alex




> 
> Alex
> 
> 
>> 
>> Thanks a lot,
>> Gilles
>> 
>>>>> [...]
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>

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

[Alex Herbert <al...@gmail.com>]

> On 12 Nov 2019, at 15:39, Gilles Sadowski <gi...@gmail.com> wrote:
> 
> Hello Alex.
> 
> Le mar. 12 nov. 2019 à 16:15, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
>> 
>> 
>> On 12/11/2019 09:06, Gilles Sadowski wrote:
>>> 2019-11-12 2:28 UTC+01:00, Alex Herbert <al...@gmail.com>:
>>>> 
>>>>> On 11 Nov 2019, at 23:40, Gilles Sadowski <gi...@gmail.com> wrote:
>>>>> 
>>>>> Hi.
>>>>> 
>>>>> Maybe I'm missing what the issues really are,
>>>> All empty japicmp reports on the site.
>>>> Some confusing empty Jacoco aggregate reports on the site.
>>>> 
>>>>> so sorry if this top-posted
>>>>> reply is beside the points:
>>>>> 1. There always have been several issues with JapiCmp (I do not remember
>>>>> exactly which; it must be in the ML archive); it never worked with
>>>>> Commons
>>>>> RNG.  [As as been mentioned in some thread and on JIRA, it might be worth
>>>>> spending time (if any) setting up the tools provided by the "revapi"
>>>>> project.]
>>>>> For now, Clirr still works fine for [RNG] (IIUC because of its "old" JDK
>>>>> target)
>>>>> and there is no need to have JapiCmp.
>>>> I’ve got japicmp to work in master. Maybe old versions had problems that
>>>> have now been fixed.
>>> I seem to remember that it failed the build for release 1.0 because there
>>> was no version to compare with (and it couldn't be prevented to run using
>>> the CP setup - cf. below).
>> 
>> Looking at the documentation I think this problem has been fixed with
>> optional properties. The appropriate property is not used in CP but a
>> project could just set it to true and the build would not fail.
>> 
>>> 
>>>> I think commons-parent should not be setup to generated empty reports when
>>>> it is not included as a profile.
>>> +1
>>> That was one of the issue.  Such plugins are optionally activated by the
>>> presence of a file, and should not run if the file is not present.  The setup
>>> works for other tools but it didn't for JapiCmp.
>>> 
>>>>> 2. IMHO, there is no need for Jacoco aggregate reports; each module has
>>>>> its
>>>>> own "plain" report, accessible under the module's "sub-site" along with
>>>>> all
>>>>> the other reports concerned with that particular body of code.  If
>>>>> designed
>>>>> correctly (and in order to work under JPMS), the modules must have
>>>>> acyclic dependencies, and it seems to me equally meaningless to have
>>>>> modules
>>>>> aggregate reports as to have aggregate reports of external dependencies.
>>>> +1.
>>>> 
>>>> I’ve disabled the aggregate report in RNG. I think it should be disabled in
>>>> commons-parent.
>>> + 1
>>> AFAICT, the latest CP enhanced automation does not take into account
>>> the "multi-module" maven feature.
>>> I had raised the question of why a "dist-archive" module is necessary:
>>> It seems to me that all the info being in the modules, the main POM
>>> should be able to generate, collect and "archive" all the artefacts under
>>> its own "target" directory.
>>> I've never dug very deep into maven, so I don't how whether it's possible
>>> or whether it's indeed to be done the (contorted, IMHO) way it is now.
>> 
>> I've tried to update RNG to work with japicmp conditionally.
>> Unfortunately once the maven plugin is included there is no way to
>> totally disable it. It will always put up an empty report in the site
>> generation.
>> 
>> The fix was to locally change CP 49 (which RNG depends on) to move all
>> the configuration inside the profile that is activated using the file
>> 'src/site/resources/profile.japicmp'.
>> 
>> A first fix with this present broke the RNG build on pre-Java8 JDKs. The
>> profile activation should also include activation if the JDK is 1.8+:
>> 
>>       <activation>
>>         <jdk>[1.8,)</jdk>
>>         <file>
>> <exists>src/site/resources/profile.japicmp</exists>
>>         </file>
>>       </activation>
>> 
>> I've rebuilt the report pages of the site using this set-up (fixed RNG,
>> fudged CP 49 locally). The JaCoCo aggregates are gone and the japicmp
>> reports are gone for all but:
>> 
>> https://commons.apache.org/proper/commons-rng/commons-rng-client-api/japicmp.html
>> 
>> https://commons.apache.org/proper/commons-rng/commons-rng-core/japicmp.html
>> 
>> https://commons.apache.org/proper/commons-rng/commons-rng-simple/japicmp.html
>> 
>> https://commons.apache.org/proper/commons-rng/commons-rng-sampling/japicmp.html
>> 
>> 
>> To fix the RNG build so that it can optionally include japicmp in the
>> report menus will require a change to the parent.
>> 
>> However some projects may not be using
>> 'src/site/resources/profile.japicmp' to activate the profile. They may
>> be directly using <japicmp.skip>false</japicmp.skip>.
>> 
>> So how to proceed with a fix for CP?
> 
> If you found a fix, please apply it to CP and "release" v50.
> If there are issues, they will be fixed in 51+.

Q. Should this be run by the dev mailing list under the prefix [parent]?



Looking at the site for the modules the top right icon is missing, e.g.

https://commons.apache.org/proper/commons-rng/commons-rng-core/index.html <https://commons.apache.org/proper/commons-rng/commons-rng-core/index.html>

It comes from ’src/site/site.xml’

For all the modules this still requires images/commons_rng.small.png, which is missing.

So:

- Duplicate this image through the entire hierarchy
- Fix it to refer to the official image: https://commons.apache.org/proper/commons-rng/images/commons_rng.small.png <https://commons.apache.org/proper/commons-rng/images/commons_rng.small.png>

The link could also be made non-relative: https://commons.apache.org/proper/commons-rng/ <https://commons.apache.org/proper/commons-rng/>

This would allow you to get back to the top level page from any of the modules pages. I don’t think this is possible at the moment.

Alex


> 
> Thanks a lot,
> Gilles
> 
>>>> [...]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>

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

[Gilles Sadowski <gi...@gmail.com>]

Hello Alex.

Le mar. 12 nov. 2019 à 16:15, Alex Herbert <al...@gmail.com> a écrit :
>
>
> On 12/11/2019 09:06, Gilles Sadowski wrote:
> > 2019-11-12 2:28 UTC+01:00, Alex Herbert <al...@gmail.com>:
> >>
> >>> On 11 Nov 2019, at 23:40, Gilles Sadowski <gi...@gmail.com> wrote:
> >>>
> >>> Hi.
> >>>
> >>> Maybe I'm missing what the issues really are,
> >> All empty japicmp reports on the site.
> >> Some confusing empty Jacoco aggregate reports on the site.
> >>
> >>> so sorry if this top-posted
> >>> reply is beside the points:
> >>> 1. There always have been several issues with JapiCmp (I do not remember
> >>> exactly which; it must be in the ML archive); it never worked with
> >>> Commons
> >>> RNG.  [As as been mentioned in some thread and on JIRA, it might be worth
> >>> spending time (if any) setting up the tools provided by the "revapi"
> >>> project.]
> >>> For now, Clirr still works fine for [RNG] (IIUC because of its "old" JDK
> >>> target)
> >>> and there is no need to have JapiCmp.
> >> I’ve got japicmp to work in master. Maybe old versions had problems that
> >> have now been fixed.
> > I seem to remember that it failed the build for release 1.0 because there
> > was no version to compare with (and it couldn't be prevented to run using
> > the CP setup - cf. below).
>
> Looking at the documentation I think this problem has been fixed with
> optional properties. The appropriate property is not used in CP but a
> project could just set it to true and the build would not fail.
>
> >
> >> I think commons-parent should not be setup to generated empty reports when
> >> it is not included as a profile.
> > +1
> > That was one of the issue.  Such plugins are optionally activated by the
> > presence of a file, and should not run if the file is not present.  The setup
> > works for other tools but it didn't for JapiCmp.
> >
> >>> 2. IMHO, there is no need for Jacoco aggregate reports; each module has
> >>> its
> >>> own "plain" report, accessible under the module's "sub-site" along with
> >>> all
> >>> the other reports concerned with that particular body of code.  If
> >>> designed
> >>> correctly (and in order to work under JPMS), the modules must have
> >>> acyclic dependencies, and it seems to me equally meaningless to have
> >>> modules
> >>> aggregate reports as to have aggregate reports of external dependencies.
> >> +1.
> >>
> >> I’ve disabled the aggregate report in RNG. I think it should be disabled in
> >> commons-parent.
> > + 1
> > AFAICT, the latest CP enhanced automation does not take into account
> > the "multi-module" maven feature.
> > I had raised the question of why a "dist-archive" module is necessary:
> > It seems to me that all the info being in the modules, the main POM
> > should be able to generate, collect and "archive" all the artefacts under
> > its own "target" directory.
> > I've never dug very deep into maven, so I don't how whether it's possible
> > or whether it's indeed to be done the (contorted, IMHO) way it is now.
>
> I've tried to update RNG to work with japicmp conditionally.
> Unfortunately once the maven plugin is included there is no way to
> totally disable it. It will always put up an empty report in the site
> generation.
>
> The fix was to locally change CP 49 (which RNG depends on) to move all
> the configuration inside the profile that is activated using the file
> 'src/site/resources/profile.japicmp'.
>
> A first fix with this present broke the RNG build on pre-Java8 JDKs. The
> profile activation should also include activation if the JDK is 1.8+:
>
>        <activation>
>          <jdk>[1.8,)</jdk>
>          <file>
> <exists>src/site/resources/profile.japicmp</exists>
>          </file>
>        </activation>
>
> I've rebuilt the report pages of the site using this set-up (fixed RNG,
> fudged CP 49 locally). The JaCoCo aggregates are gone and the japicmp
> reports are gone for all but:
>
> https://commons.apache.org/proper/commons-rng/commons-rng-client-api/japicmp.html
>
> https://commons.apache.org/proper/commons-rng/commons-rng-core/japicmp.html
>
> https://commons.apache.org/proper/commons-rng/commons-rng-simple/japicmp.html
>
> https://commons.apache.org/proper/commons-rng/commons-rng-sampling/japicmp.html
>
>
> To fix the RNG build so that it can optionally include japicmp in the
> report menus will require a change to the parent.
>
> However some projects may not be using
> 'src/site/resources/profile.japicmp' to activate the profile. They may
> be directly using <japicmp.skip>false</japicmp.skip>.
>
> So how to proceed with a fix for CP?

If you found a fix, please apply it to CP and "release" v50.
If there are issues, they will be fixed in 51+.

Thanks a lot,
Gilles

>>> [...]

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

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

[Alex Herbert <al...@gmail.com>]

On 12/11/2019 09:06, Gilles Sadowski wrote:
> 2019-11-12 2:28 UTC+01:00, Alex Herbert <al...@gmail.com>:
>>
>>> On 11 Nov 2019, at 23:40, Gilles Sadowski <gi...@gmail.com> wrote:
>>>
>>> Hi.
>>>
>>> Maybe I'm missing what the issues really are,
>> All empty japicmp reports on the site.
>> Some confusing empty Jacoco aggregate reports on the site.
>>
>>> so sorry if this top-posted
>>> reply is beside the points:
>>> 1. There always have been several issues with JapiCmp (I do not remember
>>> exactly which; it must be in the ML archive); it never worked with
>>> Commons
>>> RNG.  [As as been mentioned in some thread and on JIRA, it might be worth
>>> spending time (if any) setting up the tools provided by the "revapi"
>>> project.]
>>> For now, Clirr still works fine for [RNG] (IIUC because of its "old" JDK
>>> target)
>>> and there is no need to have JapiCmp.
>> I’ve got japicmp to work in master. Maybe old versions had problems that
>> have now been fixed.
> I seem to remember that it failed the build for release 1.0 because there
> was no version to compare with (and it couldn't be prevented to run using
> the CP setup - cf. below).

Looking at the documentation I think this problem has been fixed with 
optional properties. The appropriate property is not used in CP but a 
project could just set it to true and the build would not fail.

>
>> I think commons-parent should not be setup to generated empty reports when
>> it is not included as a profile.
> +1
> That was one of the issue.  Such plugins are optionally activated by the
> presence of a file, and should not run if the file is not present.  The setup
> works for other tools but it didn't for JapiCmp.
>
>>> 2. IMHO, there is no need for Jacoco aggregate reports; each module has
>>> its
>>> own "plain" report, accessible under the module's "sub-site" along with
>>> all
>>> the other reports concerned with that particular body of code.  If
>>> designed
>>> correctly (and in order to work under JPMS), the modules must have
>>> acyclic dependencies, and it seems to me equally meaningless to have
>>> modules
>>> aggregate reports as to have aggregate reports of external dependencies.
>> +1.
>>
>> I’ve disabled the aggregate report in RNG. I think it should be disabled in
>> commons-parent.
> + 1
> AFAICT, the latest CP enhanced automation does not take into account
> the "multi-module" maven feature.
> I had raised the question of why a "dist-archive" module is necessary:
> It seems to me that all the info being in the modules, the main POM
> should be able to generate, collect and "archive" all the artefacts under
> its own "target" directory.
> I've never dug very deep into maven, so I don't how whether it's possible
> or whether it's indeed to be done the (contorted, IMHO) way it is now.

I've tried to update RNG to work with japicmp conditionally. 
Unfortunately once the maven plugin is included there is no way to 
totally disable it. It will always put up an empty report in the site 
generation.

The fix was to locally change CP 49 (which RNG depends on) to move all 
the configuration inside the profile that is activated using the file 
'src/site/resources/profile.japicmp'.

A first fix with this present broke the RNG build on pre-Java8 JDKs. The 
profile activation should also include activation if the JDK is 1.8+:

       <activation>
         <jdk>[1.8,)</jdk>
         <file>
<exists>src/site/resources/profile.japicmp</exists>
         </file>
       </activation>

I've rebuilt the report pages of the site using this set-up (fixed RNG, 
fudged CP 49 locally). The JaCoCo aggregates are gone and the japicmp 
reports are gone for all but:

https://commons.apache.org/proper/commons-rng/commons-rng-client-api/japicmp.html

https://commons.apache.org/proper/commons-rng/commons-rng-core/japicmp.html

https://commons.apache.org/proper/commons-rng/commons-rng-simple/japicmp.html

https://commons.apache.org/proper/commons-rng/commons-rng-sampling/japicmp.html


To fix the RNG build so that it can optionally include japicmp in the 
report menus will require a change to the parent.

However some projects may not be using 
'src/site/resources/profile.japicmp' to activate the profile. They may 
be directly using <japicmp.skip>false</japicmp.skip>.

So how to proceed with a fix for CP?

Alex


> Regards,
> Gilles
>
>> It only makes sense to projects that have integration tests
>> to exercise combinations of components that cannot be tested standalone.
>>
>>> 3. People who will want more reports about some version of the library
>>> can download the project and run <whatever> locally.  It was never
>>> mandated that the web site maintains a full history of all the versions;
>>> quite
>>> the contrary, users are always (kindly) requested to upgrade to the last
>>> version of a component (and IIUC, we are asked that older versions are
>>> made more difficult to access and download).
>>>
>>> Regards,
>>> Gilles
>>>
>>> 2019-11-11 23:05 UTC+01:00, Alex Herbert <al...@gmail.com>:
>>>>
>>>>> On 11 Nov 2019, at 18:36, Gilles Sadowski <gi...@gmail.com> wrote:
>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>> I will try and find out why these are running and just remove them.
>>>>>> The pom requires this to skip aggregate reports [2]:
>>>>>>
>>>>>>       <plugin>
>>>>>>         <groupId>org.jacoco</groupId>
>>>>>>         <artifactId>jacoco-maven-plugin</artifactId>
>>>>>>         <reportSets>
>>>>>>           <reportSet>
>>>>>>             <reports>
>>>>>>               <!-- select non-aggregate reports -->
>>>>>>               <report>report</report>
>>>>>>             </reports>
>>>>>>           </reportSet>
>>>>>>         </reportSets>
>>>>>>       </plugin>
>>>>>>
>>>>>> [2] https://www.eclemma.org/jacoco/trunk/doc/maven.html
>>>>>>
>>>>>>
>>>>>> Is it OK to take my release branch and do the modifications on that
>>>>>> to:
>>>>>>
>>>>>> 1. add JAPIcmp (since the <japicmp.skip>true</japicmp.skip> in the
>>>>>> parent still generates reports)
>>>>>>
>>>>>> 2. skip JaCoCo aggregates
>>>>>>
>>>>>> to rebuild build and update the live site?
>>>>> I'd rather leave the release branch as is.
>>>>>
>>>>> IMO, the site should be fixed and built and updated from the "master"
>>>>> branch
>>>>> (since that will happen anyway the next time someone updates it).
>>>>>
>>>>> Gilles
>>>> Master has now been updated to ignore the JaCoCo aggregate report. master
>>>> is
>>>> also configured to use the new japicmp functionality. I added it when
>>>> reviewing 1.3 RC1 and noticed the japicmp report was empty. I didn’t
>>>> think
>>>> it warranted a new RC as it is just a report and I presumed this empty
>>>> report was normal. But it may be that this is the first time we released
>>>> a
>>>> component since commons-parent added japicmp without using actually
>>>> using
>>>> japicmp.
>>>>
>>>> Anyway master has the correct configuration for site builds so this
>>>> requires
>>>> no configuration changes.
>>>>
>>>> Unfortunately using master will not allow a full site generation to be
>>>> used
>>>> as a drop in replacement using only command line properties.
>>>>
>>>> Both clirr and japicmp put the version in the report so it will appear
>>>> as
>>>> 1.4-SNAPSHOT. You can dynamically update the version to compare against
>>>> but
>>>> not the current version. There is no way to set the version using
>>>> command
>>>> line parameters so you have to do this:
>>>>
>>>> mvn versions:set -DnewVersion=1.3
>>>> mvn package site -Dcommons.release.version=1.2
>>>> mvn versions:set -DnewVersion=1.4-SNAPSHOT
>>>>
>>>> This is a bit of a fudge because it updates all the POMs with a fudged
>>>> version. So although the reports now state “1.3” the code is using the
>>>> current source (from 1.4-SNAPSHOT) to build the jar file.
>>>>
>>>> For now this solution will work as the source has not changed. But once
>>>> the
>>>> source starts to diverge a site generation would produce incorrect
>>>> reports
>>>> for the current release so this is not to be used at any time to
>>>> regenerate
>>>> the entire site.
>>>>
>>>> I will try and get the site sorted using this approach by updating the
>>>> site
>>>> menus (to drop the Jacoco aggregate report) and fix japicmp.
>>>>
>>>>
>>>> —
>>>>
>>>> Issues with commons parent:
>>>>
>>>> japicmp
>>>>
>>>> For japicmp it seems the maven plugin is a bit immature in that even if
>>>> it
>>>> is set to skip it will create a menu in the reports during site
>>>> creation.
>>>>
>>>> So introducing the configuration in the main part of the pom for japicmp
>>>> in
>>>> commons-parent means that any commons codebase not using japicmp will
>>>> have
>>>> this empty report. Ideally the configuration should all be in the
>>>> profile.
>>>> So if the profile is not enabled then japicmp does not effectively
>>>> exist,
>>>> rather than relying on its broken skip report execution.
>>>>
>>>> At current commons-parent effectively forces all commons projects to
>>>> either
>>>> use japicmp or have an empty report in the site.
>>>>
>>>>
>>>> JaCoCo
>>>>
>>>> By default the aggregate reports only appear when the module has
>>>> dependencies on other modules. It thus only effects multi-module builds.
>>>> What parts of commons are multi-module? I know of:
>>>>
>>>> - RNG
>>>> - Numbers
>>>> - Geometry
>>>> - Statistics
>>>>
>>>> Are there any others?
>>>>
>>>> For all of these the following fix from RNG could be used:
>>>>
>>>>         <reportSets>
>>>>           <reportSet>
>>>>             <reports>
>>>>               <!-- select non-aggregate reports -->
>>>>               <report>report</report>
>>>>             </reports>
>>>>           </reportSet>
>>>>         </reportSets>
>>>>
>>>> Perhaps this should go into parent. Then multi-module builds would have
>>>> to
>>>> explicitly decide if they wanted an aggregate report. This should go
>>>> into
>>>> the POM for each module that wants it. Putting it into the top level POM,
>>>> or
>>>> any other module POM that has no dependencies, creates the empty report
>>>> seen
>>>> for RNG.
>>>>
>>>> Alex
>>>>
>>>>
>>>>>>>
>>>>>>> [...]
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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

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

[Gilles Sadowski <gi...@gmail.com>]

2019-11-12 2:28 UTC+01:00, Alex Herbert <al...@gmail.com>:
>
>
>> On 11 Nov 2019, at 23:40, Gilles Sadowski <gi...@gmail.com> wrote:
>>
>> Hi.
>>
>> Maybe I'm missing what the issues really are,
>
> All empty japicmp reports on the site.
> Some confusing empty Jacoco aggregate reports on the site.
>
>> so sorry if this top-posted
>> reply is beside the points:
>> 1. There always have been several issues with JapiCmp (I do not remember
>> exactly which; it must be in the ML archive); it never worked with
>> Commons
>> RNG.  [As as been mentioned in some thread and on JIRA, it might be worth
>> spending time (if any) setting up the tools provided by the "revapi"
>> project.]
>> For now, Clirr still works fine for [RNG] (IIUC because of its "old" JDK
>> target)
>> and there is no need to have JapiCmp.
>
> I’ve got japicmp to work in master. Maybe old versions had problems that
> have now been fixed.

I seem to remember that it failed the build for release 1.0 because there
was no version to compare with (and it couldn't be prevented to run using
the CP setup - cf. below).

>
> I think commons-parent should not be setup to generated empty reports when
> it is not included as a profile.

+1
That was one of the issue.  Such plugins are optionally activated by the
presence of a file, and should not run if the file is not present.  The setup
works for other tools but it didn't for JapiCmp.

>> 2. IMHO, there is no need for Jacoco aggregate reports; each module has
>> its
>> own "plain" report, accessible under the module's "sub-site" along with
>> all
>> the other reports concerned with that particular body of code.  If
>> designed
>> correctly (and in order to work under JPMS), the modules must have
>> acyclic dependencies, and it seems to me equally meaningless to have
>> modules
>> aggregate reports as to have aggregate reports of external dependencies.
>
> +1.
>
> I’ve disabled the aggregate report in RNG. I think it should be disabled in
> commons-parent.

+ 1
AFAICT, the latest CP enhanced automation does not take into account
the "multi-module" maven feature.
I had raised the question of why a "dist-archive" module is necessary:
It seems to me that all the info being in the modules, the main POM
should be able to generate, collect and "archive" all the artefacts under
its own "target" directory.
I've never dug very deep into maven, so I don't how whether it's possible
or whether it's indeed to be done the (contorted, IMHO) way it is now.

Regards,
Gilles

> It only makes sense to projects that have integration tests
> to exercise combinations of components that cannot be tested standalone.
>
>> 3. People who will want more reports about some version of the library
>> can download the project and run <whatever> locally.  It was never
>> mandated that the web site maintains a full history of all the versions;
>> quite
>> the contrary, users are always (kindly) requested to upgrade to the last
>> version of a component (and IIUC, we are asked that older versions are
>> made more difficult to access and download).
>>
>> Regards,
>> Gilles
>>
>> 2019-11-11 23:05 UTC+01:00, Alex Herbert <al...@gmail.com>:
>>>
>>>
>>>> On 11 Nov 2019, at 18:36, Gilles Sadowski <gi...@gmail.com> wrote:
>>>>
>>>>>> [...]
>>>>>>
>>>>>> I will try and find out why these are running and just remove them.
>>>>>
>>>>> The pom requires this to skip aggregate reports [2]:
>>>>>
>>>>>      <plugin>
>>>>>        <groupId>org.jacoco</groupId>
>>>>>        <artifactId>jacoco-maven-plugin</artifactId>
>>>>>        <reportSets>
>>>>>          <reportSet>
>>>>>            <reports>
>>>>>              <!-- select non-aggregate reports -->
>>>>>              <report>report</report>
>>>>>            </reports>
>>>>>          </reportSet>
>>>>>        </reportSets>
>>>>>      </plugin>
>>>>>
>>>>> [2] https://www.eclemma.org/jacoco/trunk/doc/maven.html
>>>>>
>>>>>
>>>>> Is it OK to take my release branch and do the modifications on that
>>>>> to:
>>>>>
>>>>> 1. add JAPIcmp (since the <japicmp.skip>true</japicmp.skip> in the
>>>>> parent still generates reports)
>>>>>
>>>>> 2. skip JaCoCo aggregates
>>>>>
>>>>> to rebuild build and update the live site?
>>>>
>>>> I'd rather leave the release branch as is.
>>>>
>>>> IMO, the site should be fixed and built and updated from the "master"
>>>> branch
>>>> (since that will happen anyway the next time someone updates it).
>>>>
>>>> Gilles
>>>
>>> Master has now been updated to ignore the JaCoCo aggregate report. master
>>> is
>>> also configured to use the new japicmp functionality. I added it when
>>> reviewing 1.3 RC1 and noticed the japicmp report was empty. I didn’t
>>> think
>>> it warranted a new RC as it is just a report and I presumed this empty
>>> report was normal. But it may be that this is the first time we released
>>> a
>>> component since commons-parent added japicmp without using actually
>>> using
>>> japicmp.
>>>
>>> Anyway master has the correct configuration for site builds so this
>>> requires
>>> no configuration changes.
>>>
>>> Unfortunately using master will not allow a full site generation to be
>>> used
>>> as a drop in replacement using only command line properties.
>>>
>>> Both clirr and japicmp put the version in the report so it will appear
>>> as
>>> 1.4-SNAPSHOT. You can dynamically update the version to compare against
>>> but
>>> not the current version. There is no way to set the version using
>>> command
>>> line parameters so you have to do this:
>>>
>>> mvn versions:set -DnewVersion=1.3
>>> mvn package site -Dcommons.release.version=1.2
>>> mvn versions:set -DnewVersion=1.4-SNAPSHOT
>>>
>>> This is a bit of a fudge because it updates all the POMs with a fudged
>>> version. So although the reports now state “1.3” the code is using the
>>> current source (from 1.4-SNAPSHOT) to build the jar file.
>>>
>>> For now this solution will work as the source has not changed. But once
>>> the
>>> source starts to diverge a site generation would produce incorrect
>>> reports
>>> for the current release so this is not to be used at any time to
>>> regenerate
>>> the entire site.
>>>
>>> I will try and get the site sorted using this approach by updating the
>>> site
>>> menus (to drop the Jacoco aggregate report) and fix japicmp.
>>>
>>>
>>> —
>>>
>>> Issues with commons parent:
>>>
>>> japicmp
>>>
>>> For japicmp it seems the maven plugin is a bit immature in that even if
>>> it
>>> is set to skip it will create a menu in the reports during site
>>> creation.
>>>
>>> So introducing the configuration in the main part of the pom for japicmp
>>> in
>>> commons-parent means that any commons codebase not using japicmp will
>>> have
>>> this empty report. Ideally the configuration should all be in the
>>> profile.
>>> So if the profile is not enabled then japicmp does not effectively
>>> exist,
>>> rather than relying on its broken skip report execution.
>>>
>>> At current commons-parent effectively forces all commons projects to
>>> either
>>> use japicmp or have an empty report in the site.
>>>
>>>
>>> JaCoCo
>>>
>>> By default the aggregate reports only appear when the module has
>>> dependencies on other modules. It thus only effects multi-module builds.
>>> What parts of commons are multi-module? I know of:
>>>
>>> - RNG
>>> - Numbers
>>> - Geometry
>>> - Statistics
>>>
>>> Are there any others?
>>>
>>> For all of these the following fix from RNG could be used:
>>>
>>>        <reportSets>
>>>          <reportSet>
>>>            <reports>
>>>              <!-- select non-aggregate reports -->
>>>              <report>report</report>
>>>            </reports>
>>>          </reportSet>
>>>        </reportSets>
>>>
>>> Perhaps this should go into parent. Then multi-module builds would have
>>> to
>>> explicitly decide if they wanted an aggregate report. This should go
>>> into
>>> the POM for each module that wants it. Putting it into the top level POM,
>>> or
>>> any other module POM that has no dependencies, creates the empty report
>>> seen
>>> for RNG.
>>>
>>> Alex
>>>
>>>
>>>>
>>>>>>
>>>>>>
>>>>>> [...]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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

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

[Alex Herbert <al...@gmail.com>]

> On 11 Nov 2019, at 23:40, Gilles Sadowski <gi...@gmail.com> wrote:
> 
> Hi.
> 
> Maybe I'm missing what the issues really are,

All empty japicmp reports on the site. 
Some confusing empty Jacoco aggregate reports on the site.

> so sorry if this top-posted
> reply is beside the points:
> 1. There always have been several issues with JapiCmp (I do not remember
> exactly which; it must be in the ML archive); it never worked with Commons
> RNG.  [As as been mentioned in some thread and on JIRA, it might be worth
> spending time (if any) setting up the tools provided by the "revapi" project.]
> For now, Clirr still works fine for [RNG] (IIUC because of its "old" JDK target)
> and there is no need to have JapiCmp.

I’ve got japicmp to work in master. Maybe old versions had problems that have now been fixed.

I think commons-parent should not be setup to generated empty reports when it is not included as a profile.

> 2. IMHO, there is no need for Jacoco aggregate reports; each module has its
> own "plain" report, accessible under the module's "sub-site" along with all
> the other reports concerned with that particular body of code.  If designed
> correctly (and in order to work under JPMS), the modules must have
> acyclic dependencies, and it seems to me equally meaningless to have
> modules
> aggregate reports as to have aggregate reports of external dependencies.

+1.

I’ve disabled the aggregate report in RNG. I think it should be disabled in commons-parent. It only makes sense to projects that have integration tests to exercise combinations of components that cannot be tested standalone.

> 3. People who will want more reports about some version of the library
> can download the project and run <whatever> locally.  It was never
> mandated that the web site maintains a full history of all the versions; quite
> the contrary, users are always (kindly) requested to upgrade to the last
> version of a component (and IIUC, we are asked that older versions are
> made more difficult to access and download).
> 
> Regards,
> Gilles
> 
> 2019-11-11 23:05 UTC+01:00, Alex Herbert <al...@gmail.com>:
>> 
>> 
>>> On 11 Nov 2019, at 18:36, Gilles Sadowski <gi...@gmail.com> wrote:
>>> 
>>>>> [...]
>>>>> 
>>>>> I will try and find out why these are running and just remove them.
>>>> 
>>>> The pom requires this to skip aggregate reports [2]:
>>>> 
>>>>      <plugin>
>>>>        <groupId>org.jacoco</groupId>
>>>>        <artifactId>jacoco-maven-plugin</artifactId>
>>>>        <reportSets>
>>>>          <reportSet>
>>>>            <reports>
>>>>              <!-- select non-aggregate reports -->
>>>>              <report>report</report>
>>>>            </reports>
>>>>          </reportSet>
>>>>        </reportSets>
>>>>      </plugin>
>>>> 
>>>> [2] https://www.eclemma.org/jacoco/trunk/doc/maven.html
>>>> 
>>>> 
>>>> Is it OK to take my release branch and do the modifications on that to:
>>>> 
>>>> 1. add JAPIcmp (since the <japicmp.skip>true</japicmp.skip> in the
>>>> parent still generates reports)
>>>> 
>>>> 2. skip JaCoCo aggregates
>>>> 
>>>> to rebuild build and update the live site?
>>> 
>>> I'd rather leave the release branch as is.
>>> 
>>> IMO, the site should be fixed and built and updated from the "master"
>>> branch
>>> (since that will happen anyway the next time someone updates it).
>>> 
>>> Gilles
>> 
>> Master has now been updated to ignore the JaCoCo aggregate report. master is
>> also configured to use the new japicmp functionality. I added it when
>> reviewing 1.3 RC1 and noticed the japicmp report was empty. I didn’t think
>> it warranted a new RC as it is just a report and I presumed this empty
>> report was normal. But it may be that this is the first time we released a
>> component since commons-parent added japicmp without using actually using
>> japicmp.
>> 
>> Anyway master has the correct configuration for site builds so this requires
>> no configuration changes.
>> 
>> Unfortunately using master will not allow a full site generation to be used
>> as a drop in replacement using only command line properties.
>> 
>> Both clirr and japicmp put the version in the report so it will appear as
>> 1.4-SNAPSHOT. You can dynamically update the version to compare against but
>> not the current version. There is no way to set the version using command
>> line parameters so you have to do this:
>> 
>> mvn versions:set -DnewVersion=1.3
>> mvn package site -Dcommons.release.version=1.2
>> mvn versions:set -DnewVersion=1.4-SNAPSHOT
>> 
>> This is a bit of a fudge because it updates all the POMs with a fudged
>> version. So although the reports now state “1.3” the code is using the
>> current source (from 1.4-SNAPSHOT) to build the jar file.
>> 
>> For now this solution will work as the source has not changed. But once the
>> source starts to diverge a site generation would produce incorrect reports
>> for the current release so this is not to be used at any time to regenerate
>> the entire site.
>> 
>> I will try and get the site sorted using this approach by updating the site
>> menus (to drop the Jacoco aggregate report) and fix japicmp.
>> 
>> 
>> —
>> 
>> Issues with commons parent:
>> 
>> japicmp
>> 
>> For japicmp it seems the maven plugin is a bit immature in that even if it
>> is set to skip it will create a menu in the reports during site creation.
>> 
>> So introducing the configuration in the main part of the pom for japicmp in
>> commons-parent means that any commons codebase not using japicmp will have
>> this empty report. Ideally the configuration should all be in the profile.
>> So if the profile is not enabled then japicmp does not effectively exist,
>> rather than relying on its broken skip report execution.
>> 
>> At current commons-parent effectively forces all commons projects to either
>> use japicmp or have an empty report in the site.
>> 
>> 
>> JaCoCo
>> 
>> By default the aggregate reports only appear when the module has
>> dependencies on other modules. It thus only effects multi-module builds.
>> What parts of commons are multi-module? I know of:
>> 
>> - RNG
>> - Numbers
>> - Geometry
>> - Statistics
>> 
>> Are there any others?
>> 
>> For all of these the following fix from RNG could be used:
>> 
>>        <reportSets>
>>          <reportSet>
>>            <reports>
>>              <!-- select non-aggregate reports -->
>>              <report>report</report>
>>            </reports>
>>          </reportSet>
>>        </reportSets>
>> 
>> Perhaps this should go into parent. Then multi-module builds would have to
>> explicitly decide if they wanted an aggregate report. This should go into
>> the POM for each module that wants it. Putting it into the top level POM, or
>> any other module POM that has no dependencies, creates the empty report seen
>> for RNG.
>> 
>> Alex
>> 
>> 
>>> 
>>>>> 
>>>>> 
>>>>> [...]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


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

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

[Gilles Sadowski <gi...@gmail.com>]

Hi.

Maybe I'm missing what the issues really are, so sorry if this top-posted
reply is beside the points:
1. There always have been several issues with JapiCmp (I do not remember
exactly which; it must be in the ML archive); it never worked with Commons
RNG.  [As as been mentioned in some thread and on JIRA, it might be worth
spending time (if any) setting up the tools provided by the "revapi" project.]
For now, Clirr still works fine for [RNG] (IIUC because of its "old" JDK target)
and there is no need to have JapiCmp.
2. IMHO, there is no need for Jacoco aggregate reports; each module has its
own "plain" report, accessible under the module's "sub-site" along with all
the other reports concerned with that particular body of code.  If designed
correctly (and in order to work under JPMS), the modules must have
acyclic dependencies, and it seems to me equally meaningless to have
modules
aggregate reports as to have aggregate reports of external dependencies.
3. People who will want more reports about some version of the library
can download the project and run <whatever> locally.  It was never
mandated that the web site maintains a full history of all the versions; quite
the contrary, users are always (kindly) requested to upgrade to the last
version of a component (and IIUC, we are asked that older versions are
made more difficult to access and download).

Regards,
Gilles

2019-11-11 23:05 UTC+01:00, Alex Herbert <al...@gmail.com>:
>
>
>> On 11 Nov 2019, at 18:36, Gilles Sadowski <gi...@gmail.com> wrote:
>>
>>>> [...]
>>>>
>>>> I will try and find out why these are running and just remove them.
>>>
>>> The pom requires this to skip aggregate reports [2]:
>>>
>>>       <plugin>
>>>         <groupId>org.jacoco</groupId>
>>>         <artifactId>jacoco-maven-plugin</artifactId>
>>>         <reportSets>
>>>           <reportSet>
>>>             <reports>
>>>               <!-- select non-aggregate reports -->
>>>               <report>report</report>
>>>             </reports>
>>>           </reportSet>
>>>         </reportSets>
>>>       </plugin>
>>>
>>> [2] https://www.eclemma.org/jacoco/trunk/doc/maven.html
>>>
>>>
>>> Is it OK to take my release branch and do the modifications on that to:
>>>
>>> 1. add JAPIcmp (since the <japicmp.skip>true</japicmp.skip> in the
>>> parent still generates reports)
>>>
>>> 2. skip JaCoCo aggregates
>>>
>>> to rebuild build and update the live site?
>>
>> I'd rather leave the release branch as is.
>>
>> IMO, the site should be fixed and built and updated from the "master"
>> branch
>> (since that will happen anyway the next time someone updates it).
>>
>> Gilles
>
> Master has now been updated to ignore the JaCoCo aggregate report. master is
> also configured to use the new japicmp functionality. I added it when
> reviewing 1.3 RC1 and noticed the japicmp report was empty. I didn’t think
> it warranted a new RC as it is just a report and I presumed this empty
> report was normal. But it may be that this is the first time we released a
> component since commons-parent added japicmp without using actually using
> japicmp.
>
> Anyway master has the correct configuration for site builds so this requires
> no configuration changes.
>
> Unfortunately using master will not allow a full site generation to be used
> as a drop in replacement using only command line properties.
>
> Both clirr and japicmp put the version in the report so it will appear as
> 1.4-SNAPSHOT. You can dynamically update the version to compare against but
> not the current version. There is no way to set the version using command
> line parameters so you have to do this:
>
> mvn versions:set -DnewVersion=1.3
> mvn package site -Dcommons.release.version=1.2
> mvn versions:set -DnewVersion=1.4-SNAPSHOT
>
> This is a bit of a fudge because it updates all the POMs with a fudged
> version. So although the reports now state “1.3” the code is using the
> current source (from 1.4-SNAPSHOT) to build the jar file.
>
> For now this solution will work as the source has not changed. But once the
> source starts to diverge a site generation would produce incorrect reports
> for the current release so this is not to be used at any time to regenerate
> the entire site.
>
> I will try and get the site sorted using this approach by updating the site
> menus (to drop the Jacoco aggregate report) and fix japicmp.
>
>
> —
>
> Issues with commons parent:
>
> japicmp
>
> For japicmp it seems the maven plugin is a bit immature in that even if it
> is set to skip it will create a menu in the reports during site creation.
>
> So introducing the configuration in the main part of the pom for japicmp in
> commons-parent means that any commons codebase not using japicmp will have
> this empty report. Ideally the configuration should all be in the profile.
> So if the profile is not enabled then japicmp does not effectively exist,
> rather than relying on its broken skip report execution.
>
> At current commons-parent effectively forces all commons projects to either
> use japicmp or have an empty report in the site.
>
>
> JaCoCo
>
> By default the aggregate reports only appear when the module has
> dependencies on other modules. It thus only effects multi-module builds.
> What parts of commons are multi-module? I know of:
>
> - RNG
> - Numbers
> - Geometry
> - Statistics
>
> Are there any others?
>
> For all of these the following fix from RNG could be used:
>
>         <reportSets>
>           <reportSet>
>             <reports>
>               <!-- select non-aggregate reports -->
>               <report>report</report>
>             </reports>
>           </reportSet>
>         </reportSets>
>
> Perhaps this should go into parent. Then multi-module builds would have to
> explicitly decide if they wanted an aggregate report. This should go into
> the POM for each module that wants it. Putting it into the top level POM, or
> any other module POM that has no dependencies, creates the empty report seen
> for RNG.
>
> Alex
>
>
>>
>>>>
>>>>
>>>> [...]

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

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

[Alex Herbert <al...@gmail.com>]

> On 11 Nov 2019, at 18:36, Gilles Sadowski <gi...@gmail.com> wrote:
> 
>>> [...]
>>> 
>>> I will try and find out why these are running and just remove them.
>> 
>> The pom requires this to skip aggregate reports [2]:
>> 
>>       <plugin>
>>         <groupId>org.jacoco</groupId>
>>         <artifactId>jacoco-maven-plugin</artifactId>
>>         <reportSets>
>>           <reportSet>
>>             <reports>
>>               <!-- select non-aggregate reports -->
>>               <report>report</report>
>>             </reports>
>>           </reportSet>
>>         </reportSets>
>>       </plugin>
>> 
>> [2] https://www.eclemma.org/jacoco/trunk/doc/maven.html
>> 
>> 
>> Is it OK to take my release branch and do the modifications on that to:
>> 
>> 1. add JAPIcmp (since the <japicmp.skip>true</japicmp.skip> in the
>> parent still generates reports)
>> 
>> 2. skip JaCoCo aggregates
>> 
>> to rebuild build and update the live site?
> 
> I'd rather leave the release branch as is.
> 
> IMO, the site should be fixed and built and updated from the "master" branch
> (since that will happen anyway the next time someone updates it).
> 
> Gilles

Master has now been updated to ignore the JaCoCo aggregate report. master is also configured to use the new japicmp functionality. I added it when reviewing 1.3 RC1 and noticed the japicmp report was empty. I didn’t think it warranted a new RC as it is just a report and I presumed this empty report was normal. But it may be that this is the first time we released a component since commons-parent added japicmp without using actually using japicmp. 

Anyway master has the correct configuration for site builds so this requires no configuration changes.

Unfortunately using master will not allow a full site generation to be used as a drop in replacement using only command line properties.

Both clirr and japicmp put the version in the report so it will appear as 1.4-SNAPSHOT. You can dynamically update the version to compare against but not the current version. There is no way to set the version using command line parameters so you have to do this:

mvn versions:set -DnewVersion=1.3
mvn package site -Dcommons.release.version=1.2
mvn versions:set -DnewVersion=1.4-SNAPSHOT

This is a bit of a fudge because it updates all the POMs with a fudged version. So although the reports now state “1.3” the code is using the current source (from 1.4-SNAPSHOT) to build the jar file.

For now this solution will work as the source has not changed. But once the source starts to diverge a site generation would produce incorrect reports for the current release so this is not to be used at any time to regenerate the entire site.

I will try and get the site sorted using this approach by updating the site menus (to drop the Jacoco aggregate report) and fix japicmp.


—

Issues with commons parent:

japicmp

For japicmp it seems the maven plugin is a bit immature in that even if it is set to skip it will create a menu in the reports during site creation.

So introducing the configuration in the main part of the pom for japicmp in commons-parent means that any commons codebase not using japicmp will have this empty report. Ideally the configuration should all be in the profile. So if the profile is not enabled then japicmp does not effectively exist, rather than relying on its broken skip report execution.

At current commons-parent effectively forces all commons projects to either use japicmp or have an empty report in the site.


JaCoCo

By default the aggregate reports only appear when the module has dependencies on other modules. It thus only effects multi-module builds. What parts of commons are multi-module? I know of:

- RNG
- Numbers
- Geometry
- Statistics

Are there any others?

For all of these the following fix from RNG could be used:

        <reportSets>
          <reportSet>
            <reports>
              <!-- select non-aggregate reports -->
              <report>report</report>
            </reports>
          </reportSet>
        </reportSets>

Perhaps this should go into parent. Then multi-module builds would have to explicitly decide if they wanted an aggregate report. This should go into the POM for each module that wants it. Putting it into the top level POM, or any other module POM that has no dependencies, creates the empty report seen for RNG.

Alex


> 
>>> 
>>> 
>>> [...]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


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

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

[Gilles Sadowski <gi...@gmail.com>]

> > [...]
> >
> > I will try and find out why these are running and just remove them.
>
> The pom requires this to skip aggregate reports [2]:
>
>        <plugin>
>          <groupId>org.jacoco</groupId>
>          <artifactId>jacoco-maven-plugin</artifactId>
>          <reportSets>
>            <reportSet>
>              <reports>
>                <!-- select non-aggregate reports -->
>                <report>report</report>
>              </reports>
>            </reportSet>
>          </reportSets>
>        </plugin>
>
> [2] https://www.eclemma.org/jacoco/trunk/doc/maven.html
>
>
> Is it OK to take my release branch and do the modifications on that to:
>
> 1. add JAPIcmp (since the <japicmp.skip>true</japicmp.skip> in the
> parent still generates reports)
>
> 2. skip JaCoCo aggregates
>
> to rebuild build and update the live site?

I'd rather leave the release branch as is.

IMO, the site should be fixed and built and updated from the "master" branch
(since that will happen anyway the next time someone updates it).

Gilles

> >
> >
> > [...]

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

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

[Alex Herbert <al...@gmail.com>]

On 11/11/2019 17:55, Alex Herbert wrote:
> On 11/11/2019 16:43, Gary Gregory wrote:
>> The JApiCmp and JaCoCo reports are empty. You'll want to make sure 
>> you fix
>> that before publishing the site.
>
> Good spot. Unfortunately I've already pushed to the live site so I'll 
> have to fix it in-place.
>
>
> JAPIcmp was introduced in parent-49 but set to disabled by default. 
> RNG did not use it for this release. It still appears in the menu but 
> the report is empty. So is this an issue with commons-parent?
>
> I can fix JAPIcmp by running the report because I have made the master 
> branch use JAPIcmp.
>
>
> Something strange is happening with JaCoCo for the multi-module site 
> build.
>
> These are fine:
>
> https://commons.apache.org/proper/commons-rng/commons-rng-core/jacoco/index.html 
>
>
> https://commons.apache.org/proper/commons-rng/commons-rng-sampling/jacoco/index.html 
>
>
> https://commons.apache.org/proper/commons-rng/commons-rng-simple/jacoco/index.html 
>
>
> This is missing:
>
> https://commons.apache.org/proper/commons-rng/commons-rng-client-api/jacoco-aggregate/index.html 
>
>
> The client API module has only interfaces. There are no tests. So when 
> jacoco runs it states:
>
> [INFO] --- jacoco-maven-plugin:0.8.4:report (report) @ 
> commons-rng-client-api ---
> [INFO] Skipping JaCoCo execution due to missing execution data file.
>
> But for some reason it still runs the aggregate report. The same is 
> true for the top level web site page which is why there is a JaCoCo 
> Aggregate report listed here:
>
> https://commons.apache.org/proper/commons-rng/project-reports.html
>
> But is it empty.
>
> This may have always been the case.
>
> It may be due to an update to JaCoCo which is now running the 
> aggregate report by default when previously it did not.
>
> The JaCoCo docs [1] state that:
>
> "Creates a structured code coverage report (HTML, XML, and CSV) from 
> multiple projects within reactor. The report is created from all 
> modules this project depends on."
>
> So all the modules that have dependencies to other modules get an 
> aggregate report. But it also appears for those with no dependencies 
> to other modeles. Either way this is not needed for RNG as each module 
> has tests to ensure coverage within the module. It is more a report 
> for coverage of integration tests.
>
> I will try and find out why these are running and just remove them.

The pom requires this to skip aggregate reports [2]:

       <plugin>
         <groupId>org.jacoco</groupId>
         <artifactId>jacoco-maven-plugin</artifactId>
         <reportSets>
           <reportSet>
             <reports>
               <!-- select non-aggregate reports -->
               <report>report</report>
             </reports>
           </reportSet>
         </reportSets>
       </plugin>

[2] https://www.eclemma.org/jacoco/trunk/doc/maven.html


Is it OK to take my release branch and do the modifications on that to:

1. add JAPIcmp (since the <japicmp.skip>true</japicmp.skip> in the 
parent still generates reports)

2. skip JaCoCo aggregates

to rebuild build and update the live site?


>
>
> [1] https://www.eclemma.org/jacoco/trunk/doc/report-aggregate-mojo.html
>
>
>>
>> Gary
>>
>> On Tue, Nov 5, 2019 at 11:36 AM Alex Herbert <ah...@apache.org> 
>> wrote:
>>
>>> We have fixed quite a few bugs and added some significant enhancements
>>> since Apache Commons RNG 1.2 was released, so I would like to release
>>> Apache Commons RNG 1.3.
>>>
>>> Apache Commons RNG 1.3 RC1 is available for review here:
>>> https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/
>>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/
>>>
>>> Tag name:
>>>     RNG_1_3_RC1 (signature can be checked from git using 'git tag -v
>>> RNG_1_3_RC1')
>>>
>>> Tag URL:
>>>
>>> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=43f290e68c31e5bea6cde97c7e999c2e1f2562b2 
>>>
>>>
>>> Commit ID the tag points at:
>>>     43f290e68c31e5bea6cde97c7e999c2e1f2562b2
>>>
>>> Maven artifacts are here:
>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1476/org/apache/commons/ 
>>>
>>>
>>> These are the artifacts and their SHA 512 hashes:
>>> 310c0582b80c60fb159846f9615c7952b3c405265955392d77b16d7cfac9e8c5f2c680686e526b412ab8b4356ef9ecd07977764c31db8e02bef40e37b47ac27a 
>>>
>>>
>>> commons-rng-1.0-bin.tar.gz
>>> e0247ea82aff57cc86ac904ae482c193b7edd5253d26f87fc590b50a738d5fa5c4a6b3b24cd6a48c459e18156ade2588d8c9d12c9a04d15570780240d29ef406 
>>>
>>>
>>> commons-rng-1.0-bin.zip
>>> f33b922a9d8bc6098bd0e9a98859b17e1cdda21922f136b568868b21af274fdf3d78456a5c73c26c665205a22493836d59b1d33822c4a5c58e82ba64eadcb5e1 
>>>
>>>
>>> commons-rng-1.0-src.tar.gz
>>> ef4fe63ebbd76e8d95b5f054fed76a40a85f5dd99ca2406a31fb95b593ed3d96b29389bf82424e18895192751689d7590404c8b1d90b28878271c79cad3be18b 
>>>
>>>
>>> commons-rng-1.0-src.zip
>>>
>>> The source code contains examples that are not part of the public API.
>>> These examples contain Java 9 modules and are enabled using a profile
>>> (see below).
>>>
>>> An error when building the Java 9 modules site/javadoc under JDK 11 
>>> is a
>>> known issue as the javadoc command errors when documenting Java 9
>>> modules that include code from the unamed module.
>>>
>>> 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 site' using:
>>>
>>> ***
>>> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
>>> 2018-10-24T19:41:47+01:00)
>>> Maven home: /usr/local/apache-maven-3.6.0
>>> Java version: 1.8.0_222, vendor: Private Build, runtime:
>>> /usr/lib/jvm/java-8-openjdk-amd64/jre
>>> Default locale: en_GB, platform encoding: UTF-8
>>> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
>>> "unix"
>>> ***
>>>
>>> ***
>>> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
>>> 2018-10-24T19:41:47+01:00)
>>> Maven home: /usr/local/apache-maven-3.6.0
>>> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
>>> /usr/lib/jvm/jdk-11.0.5+10
>>> Default locale: en_GB, platform encoding: UTF-8
>>> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
>>> "unix"
>>> ***
>>>
>>> Java 9 modules in the examples modules.
>>>
>>> 'mvn -Pcommons-rng-examples clean install site' using:
>>>
>>> ***
>>> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
>>> 2018-10-24T19:41:47+01:00)
>>> Maven home: /usr/local/apache-maven-3.6.0
>>> Java version: 9, vendor: Oracle Corporation, runtime: 
>>> /usr/lib/jvm/jdk-9
>>> Default locale: en_GB, platform encoding: UTF-8
>>> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
>>> "unix"
>>> ***
>>>
>>> 'mvn -Pcommons-rng-examples clean install' using:
>>>
>>> ***
>>> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
>>> 2018-10-24T19:41:47+01:00)
>>> Maven home: /usr/local/apache-maven-3.6.0
>>> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
>>> /usr/lib/jvm/jdk-11.0.5+10
>>> Default locale: en_GB, platform encoding: UTF-8
>>> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
>>> "unix"
>>> ***
>>>
>>> Details of changes since 1.2 are in the release notes:
>>>
>>> https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/RELEASE-NOTES.txt 
>>>
>>>
>>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/changes-report.html 
>>>
>>>
>>> Site:
>>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/index.html
>>>       (note some *relative* links are broken and the 1.3 directories 
>>> are
>>> not yet created - these will be OK once the site is deployed.)
>>>
>>> CLIRR Report (compared to 1.2):
>>>
>>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-client-api/clirr-report.html 
>>>
>>>
>>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-core/clirr-report.html 
>>>
>>>
>>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-simple/clirr-report.html 
>>>
>>>
>>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-sampling/clirr-report.html 
>>>
>>>
>>> RAT Report:
>>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/rat-report.html 
>>>
>>>
>>> KEYS:
>>>     https://www.apache.org/dist/commons/KEYS
>>>
>>> Please review the release candidate and vote.
>>> This vote will close no sooner that 72 hours from now.
>>>
>>>     [ ] +1 Release these artifacts
>>>     [ ] +0 OK, but...
>>>     [ ] -0 OK, but really should fix...
>>>     [ ] -1 I oppose this release because...
>>>
>>> Thank you,
>>>
>>> Alex Herbert,
>>> Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)
>>>
>>> For following is intended as a helper and refresher for reviewers.
>>>
>>> Validating a release candidate
>>> ==============================
>>>
>>> These guidelines are NOT complete.
>>>
>>> Requirements: Git, Java, Maven.
>>>
>>> You can validate a release from a release candidate (RC) tag as 
>>> follows.
>>>
>>> 1) Clone and checkout the RC tag
>>>
>>> git clone https://gitbox.apache.org/repos/asf/commons-rng.git --branch
>>> RNG_1_3_RC1 commons-rng-1.3-RC1
>>> cd commons-rng-1.3-RC1
>>>
>>> 2) Check Apache licenses
>>>
>>> This step is not required if the site includes a RAT report page which
>>> you then must check.
>>>
>>> mvn apache-rat:check
>>>
>>> 3) Check binary compatibility
>>>
>>> Older components still use Apache Clirr:
>>>
>>> This step is not required if the site includes a Clirr report page 
>>> which
>>> you then must check.
>>>
>>> mvn clirr:check
>>>
>>> JApiCmp is not used in this component.
>>>
>>>
>>> 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
>>>
>>> -the end-
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>

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

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

[Gilles Sadowski <gi...@gmail.com>]

Hello.

> [...]
>
> This may have always been the case.

Yes.

Gilles

> [...]

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

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

[Gary Gregory <ga...@gmail.com>]

I usually run site builds with -P jacoco and -P japicmp

Gary

On Mon, Nov 11, 2019 at 12:55 PM Alex Herbert <al...@gmail.com>
wrote:

> On 11/11/2019 16:43, Gary Gregory wrote:
> > The JApiCmp and JaCoCo reports are empty. You'll want to make sure you
> fix
> > that before publishing the site.
>
> Good spot. Unfortunately I've already pushed to the live site so I'll
> have to fix it in-place.
>
>
> JAPIcmp was introduced in parent-49 but set to disabled by default. RNG
> did not use it for this release. It still appears in the menu but the
> report is empty. So is this an issue with commons-parent?
>
> I can fix JAPIcmp by running the report because I have made the master
> branch use JAPIcmp.
>
>
> Something strange is happening with JaCoCo for the multi-module site build.
>
> These are fine:
>
>
> https://commons.apache.org/proper/commons-rng/commons-rng-core/jacoco/index.html
>
>
> https://commons.apache.org/proper/commons-rng/commons-rng-sampling/jacoco/index.html
>
>
> https://commons.apache.org/proper/commons-rng/commons-rng-simple/jacoco/index.html
>
> This is missing:
>
>
> https://commons.apache.org/proper/commons-rng/commons-rng-client-api/jacoco-aggregate/index.html
>
> The client API module has only interfaces. There are no tests. So when
> jacoco runs it states:
>
> [INFO] --- jacoco-maven-plugin:0.8.4:report (report) @
> commons-rng-client-api ---
> [INFO] Skipping JaCoCo execution due to missing execution data file.
>
> But for some reason it still runs the aggregate report. The same is true
> for the top level web site page which is why there is a JaCoCo Aggregate
> report listed here:
>
> https://commons.apache.org/proper/commons-rng/project-reports.html
>
> But is it empty.
>
> This may have always been the case.
>
> It may be due to an update to JaCoCo which is now running the aggregate
> report by default when previously it did not.
>
> The JaCoCo docs [1] state that:
>
> "Creates a structured code coverage report (HTML, XML, and CSV) from
> multiple projects within reactor. The report is created from all modules
> this project depends on."
>
> So all the modules that have dependencies to other modules get an
> aggregate report. But it also appears for those with no dependencies to
> other modeles. Either way this is not needed for RNG as each module has
> tests to ensure coverage within the module. It is more a report for
> coverage of integration tests.
>
> I will try and find out why these are running and just remove them.
>
>
> [1] https://www.eclemma.org/jacoco/trunk/doc/report-aggregate-mojo.html
>
>
> >
> > Gary
> >
> > On Tue, Nov 5, 2019 at 11:36 AM Alex Herbert <ah...@apache.org>
> wrote:
> >
> >> We have fixed quite a few bugs and added some significant enhancements
> >> since Apache Commons RNG 1.2 was released, so I would like to release
> >> Apache Commons RNG 1.3.
> >>
> >> Apache Commons RNG 1.3 RC1 is available for review here:
> >>     https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/
> >>     https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/
> >>
> >> Tag name:
> >>     RNG_1_3_RC1 (signature can be checked from git using 'git tag -v
> >> RNG_1_3_RC1')
> >>
> >> Tag URL:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=43f290e68c31e5bea6cde97c7e999c2e1f2562b2
> >>
> >> Commit ID the tag points at:
> >>     43f290e68c31e5bea6cde97c7e999c2e1f2562b2
> >>
> >> Maven artifacts are here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1476/org/apache/commons/
> >>
> >> These are the artifacts and their SHA 512 hashes:
> >>
> 310c0582b80c60fb159846f9615c7952b3c405265955392d77b16d7cfac9e8c5f2c680686e526b412ab8b4356ef9ecd07977764c31db8e02bef40e37b47ac27a
> >>
> >> commons-rng-1.0-bin.tar.gz
> >>
> e0247ea82aff57cc86ac904ae482c193b7edd5253d26f87fc590b50a738d5fa5c4a6b3b24cd6a48c459e18156ade2588d8c9d12c9a04d15570780240d29ef406
> >>
> >> commons-rng-1.0-bin.zip
> >>
> f33b922a9d8bc6098bd0e9a98859b17e1cdda21922f136b568868b21af274fdf3d78456a5c73c26c665205a22493836d59b1d33822c4a5c58e82ba64eadcb5e1
> >>
> >> commons-rng-1.0-src.tar.gz
> >>
> ef4fe63ebbd76e8d95b5f054fed76a40a85f5dd99ca2406a31fb95b593ed3d96b29389bf82424e18895192751689d7590404c8b1d90b28878271c79cad3be18b
> >>
> >> commons-rng-1.0-src.zip
> >>
> >> The source code contains examples that are not part of the public API.
> >> These examples contain Java 9 modules and are enabled using a profile
> >> (see below).
> >>
> >> An error when building the Java 9 modules site/javadoc under JDK 11 is a
> >> known issue as the javadoc command errors when documenting Java 9
> >> modules that include code from the unamed module.
> >>
> >> 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 site' using:
> >>
> >> ***
> >> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> >> 2018-10-24T19:41:47+01:00)
> >> Maven home: /usr/local/apache-maven-3.6.0
> >> Java version: 1.8.0_222, vendor: Private Build, runtime:
> >> /usr/lib/jvm/java-8-openjdk-amd64/jre
> >> Default locale: en_GB, platform encoding: UTF-8
> >> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
> >> "unix"
> >> ***
> >>
> >> ***
> >> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> >> 2018-10-24T19:41:47+01:00)
> >> Maven home: /usr/local/apache-maven-3.6.0
> >> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
> >> /usr/lib/jvm/jdk-11.0.5+10
> >> Default locale: en_GB, platform encoding: UTF-8
> >> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
> >> "unix"
> >> ***
> >>
> >> Java 9 modules in the examples modules.
> >>
> >> 'mvn -Pcommons-rng-examples clean install site' using:
> >>
> >> ***
> >> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> >> 2018-10-24T19:41:47+01:00)
> >> Maven home: /usr/local/apache-maven-3.6.0
> >> Java version: 9, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-9
> >> Default locale: en_GB, platform encoding: UTF-8
> >> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
> >> "unix"
> >> ***
> >>
> >> 'mvn -Pcommons-rng-examples clean install' using:
> >>
> >> ***
> >> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> >> 2018-10-24T19:41:47+01:00)
> >> Maven home: /usr/local/apache-maven-3.6.0
> >> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
> >> /usr/lib/jvm/jdk-11.0.5+10
> >> Default locale: en_GB, platform encoding: UTF-8
> >> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
> >> "unix"
> >> ***
> >>
> >> Details of changes since 1.2 are in the release notes:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/RELEASE-NOTES.txt
> >>
> >>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/changes-report.html
> >>
> >> Site:
> >> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/index.html
> >>       (note some *relative* links are broken and the 1.3 directories are
> >> not yet created - these will be OK once the site is deployed.)
> >>
> >> CLIRR Report (compared to 1.2):
> >>
> >>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-client-api/clirr-report.html
> >>
> >>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-core/clirr-report.html
> >>
> >>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-simple/clirr-report.html
> >>
> >>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-sampling/clirr-report.html
> >>
> >> RAT Report:
> >>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/rat-report.html
> >>
> >> KEYS:
> >>     https://www.apache.org/dist/commons/KEYS
> >>
> >> Please review the release candidate and vote.
> >> This vote will close no sooner that 72 hours from now.
> >>
> >>     [ ] +1 Release these artifacts
> >>     [ ] +0 OK, but...
> >>     [ ] -0 OK, but really should fix...
> >>     [ ] -1 I oppose this release because...
> >>
> >> Thank you,
> >>
> >> Alex Herbert,
> >> Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)
> >>
> >> For following is intended as a helper and refresher for reviewers.
> >>
> >> Validating a release candidate
> >> ==============================
> >>
> >> These guidelines are NOT complete.
> >>
> >> Requirements: Git, Java, Maven.
> >>
> >> You can validate a release from a release candidate (RC) tag as follows.
> >>
> >> 1) Clone and checkout the RC tag
> >>
> >> git clone https://gitbox.apache.org/repos/asf/commons-rng.git --branch
> >> RNG_1_3_RC1 commons-rng-1.3-RC1
> >> cd commons-rng-1.3-RC1
> >>
> >> 2) Check Apache licenses
> >>
> >> This step is not required if the site includes a RAT report page which
> >> you then must check.
> >>
> >> mvn apache-rat:check
> >>
> >> 3) Check binary compatibility
> >>
> >> Older components still use Apache Clirr:
> >>
> >> This step is not required if the site includes a Clirr report page which
> >> you then must check.
> >>
> >> mvn clirr:check
> >>
> >> JApiCmp is not used in this component.
> >>
> >>
> >> 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
> >>
> >> -the end-
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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

[Alex Herbert <al...@gmail.com>]

On 11/11/2019 16:43, Gary Gregory wrote:
> The JApiCmp and JaCoCo reports are empty. You'll want to make sure you fix
> that before publishing the site.

Good spot. Unfortunately I've already pushed to the live site so I'll 
have to fix it in-place.


JAPIcmp was introduced in parent-49 but set to disabled by default. RNG 
did not use it for this release. It still appears in the menu but the 
report is empty. So is this an issue with commons-parent?

I can fix JAPIcmp by running the report because I have made the master 
branch use JAPIcmp.


Something strange is happening with JaCoCo for the multi-module site build.

These are fine:

https://commons.apache.org/proper/commons-rng/commons-rng-core/jacoco/index.html

https://commons.apache.org/proper/commons-rng/commons-rng-sampling/jacoco/index.html

https://commons.apache.org/proper/commons-rng/commons-rng-simple/jacoco/index.html

This is missing:

https://commons.apache.org/proper/commons-rng/commons-rng-client-api/jacoco-aggregate/index.html

The client API module has only interfaces. There are no tests. So when 
jacoco runs it states:

[INFO] --- jacoco-maven-plugin:0.8.4:report (report) @ 
commons-rng-client-api ---
[INFO] Skipping JaCoCo execution due to missing execution data file.

But for some reason it still runs the aggregate report. The same is true 
for the top level web site page which is why there is a JaCoCo Aggregate 
report listed here:

https://commons.apache.org/proper/commons-rng/project-reports.html

But is it empty.

This may have always been the case.

It may be due to an update to JaCoCo which is now running the aggregate 
report by default when previously it did not.

The JaCoCo docs [1] state that:

"Creates a structured code coverage report (HTML, XML, and CSV) from 
multiple projects within reactor. The report is created from all modules 
this project depends on."

So all the modules that have dependencies to other modules get an 
aggregate report. But it also appears for those with no dependencies to 
other modeles. Either way this is not needed for RNG as each module has 
tests to ensure coverage within the module. It is more a report for 
coverage of integration tests.

I will try and find out why these are running and just remove them.


[1] https://www.eclemma.org/jacoco/trunk/doc/report-aggregate-mojo.html


>
> Gary
>
> On Tue, Nov 5, 2019 at 11:36 AM Alex Herbert <ah...@apache.org> wrote:
>
>> We have fixed quite a few bugs and added some significant enhancements
>> since Apache Commons RNG 1.2 was released, so I would like to release
>> Apache Commons RNG 1.3.
>>
>> Apache Commons RNG 1.3 RC1 is available for review here:
>>     https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/
>>     https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/
>>
>> Tag name:
>>     RNG_1_3_RC1 (signature can be checked from git using 'git tag -v
>> RNG_1_3_RC1')
>>
>> Tag URL:
>>
>> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=43f290e68c31e5bea6cde97c7e999c2e1f2562b2
>>
>> Commit ID the tag points at:
>>     43f290e68c31e5bea6cde97c7e999c2e1f2562b2
>>
>> Maven artifacts are here:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1476/org/apache/commons/
>>
>> These are the artifacts and their SHA 512 hashes:
>> 310c0582b80c60fb159846f9615c7952b3c405265955392d77b16d7cfac9e8c5f2c680686e526b412ab8b4356ef9ecd07977764c31db8e02bef40e37b47ac27a
>>
>> commons-rng-1.0-bin.tar.gz
>> e0247ea82aff57cc86ac904ae482c193b7edd5253d26f87fc590b50a738d5fa5c4a6b3b24cd6a48c459e18156ade2588d8c9d12c9a04d15570780240d29ef406
>>
>> commons-rng-1.0-bin.zip
>> f33b922a9d8bc6098bd0e9a98859b17e1cdda21922f136b568868b21af274fdf3d78456a5c73c26c665205a22493836d59b1d33822c4a5c58e82ba64eadcb5e1
>>
>> commons-rng-1.0-src.tar.gz
>> ef4fe63ebbd76e8d95b5f054fed76a40a85f5dd99ca2406a31fb95b593ed3d96b29389bf82424e18895192751689d7590404c8b1d90b28878271c79cad3be18b
>>
>> commons-rng-1.0-src.zip
>>
>> The source code contains examples that are not part of the public API.
>> These examples contain Java 9 modules and are enabled using a profile
>> (see below).
>>
>> An error when building the Java 9 modules site/javadoc under JDK 11 is a
>> known issue as the javadoc command errors when documenting Java 9
>> modules that include code from the unamed module.
>>
>> 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 site' using:
>>
>> ***
>> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
>> 2018-10-24T19:41:47+01:00)
>> Maven home: /usr/local/apache-maven-3.6.0
>> Java version: 1.8.0_222, vendor: Private Build, runtime:
>> /usr/lib/jvm/java-8-openjdk-amd64/jre
>> Default locale: en_GB, platform encoding: UTF-8
>> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
>> "unix"
>> ***
>>
>> ***
>> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
>> 2018-10-24T19:41:47+01:00)
>> Maven home: /usr/local/apache-maven-3.6.0
>> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
>> /usr/lib/jvm/jdk-11.0.5+10
>> Default locale: en_GB, platform encoding: UTF-8
>> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
>> "unix"
>> ***
>>
>> Java 9 modules in the examples modules.
>>
>> 'mvn -Pcommons-rng-examples clean install site' using:
>>
>> ***
>> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
>> 2018-10-24T19:41:47+01:00)
>> Maven home: /usr/local/apache-maven-3.6.0
>> Java version: 9, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-9
>> Default locale: en_GB, platform encoding: UTF-8
>> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
>> "unix"
>> ***
>>
>> 'mvn -Pcommons-rng-examples clean install' using:
>>
>> ***
>> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
>> 2018-10-24T19:41:47+01:00)
>> Maven home: /usr/local/apache-maven-3.6.0
>> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
>> /usr/lib/jvm/jdk-11.0.5+10
>> Default locale: en_GB, platform encoding: UTF-8
>> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
>> "unix"
>> ***
>>
>> Details of changes since 1.2 are in the release notes:
>>
>> https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/RELEASE-NOTES.txt
>>
>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/changes-report.html
>>
>> Site:
>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/index.html
>>       (note some *relative* links are broken and the 1.3 directories are
>> not yet created - these will be OK once the site is deployed.)
>>
>> CLIRR Report (compared to 1.2):
>>
>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-client-api/clirr-report.html
>>
>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-core/clirr-report.html
>>
>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-simple/clirr-report.html
>>
>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-sampling/clirr-report.html
>>
>> RAT Report:
>> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/rat-report.html
>>
>> KEYS:
>>     https://www.apache.org/dist/commons/KEYS
>>
>> Please review the release candidate and vote.
>> This vote will close no sooner that 72 hours from now.
>>
>>     [ ] +1 Release these artifacts
>>     [ ] +0 OK, but...
>>     [ ] -0 OK, but really should fix...
>>     [ ] -1 I oppose this release because...
>>
>> Thank you,
>>
>> Alex Herbert,
>> Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)
>>
>> For following is intended as a helper and refresher for reviewers.
>>
>> Validating a release candidate
>> ==============================
>>
>> These guidelines are NOT complete.
>>
>> Requirements: Git, Java, Maven.
>>
>> You can validate a release from a release candidate (RC) tag as follows.
>>
>> 1) Clone and checkout the RC tag
>>
>> git clone https://gitbox.apache.org/repos/asf/commons-rng.git --branch
>> RNG_1_3_RC1 commons-rng-1.3-RC1
>> cd commons-rng-1.3-RC1
>>
>> 2) Check Apache licenses
>>
>> This step is not required if the site includes a RAT report page which
>> you then must check.
>>
>> mvn apache-rat:check
>>
>> 3) Check binary compatibility
>>
>> Older components still use Apache Clirr:
>>
>> This step is not required if the site includes a Clirr report page which
>> you then must check.
>>
>> mvn clirr:check
>>
>> JApiCmp is not used in this component.
>>
>>
>> 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
>>
>> -the end-
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>

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

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

[Gary Gregory <ga...@gmail.com>]

The JApiCmp and JaCoCo reports are empty. You'll want to make sure you fix
that before publishing the site.

Gary

On Tue, Nov 5, 2019 at 11:36 AM Alex Herbert <ah...@apache.org> wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons RNG 1.2 was released, so I would like to release
> Apache Commons RNG 1.3.
>
> Apache Commons RNG 1.3 RC1 is available for review here:
>    https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/
>    https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/
>
> Tag name:
>    RNG_1_3_RC1 (signature can be checked from git using 'git tag -v
> RNG_1_3_RC1')
>
> Tag URL:
>
> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=43f290e68c31e5bea6cde97c7e999c2e1f2562b2
>
> Commit ID the tag points at:
>    43f290e68c31e5bea6cde97c7e999c2e1f2562b2
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1476/org/apache/commons/
>
> These are the artifacts and their SHA 512 hashes:
> 310c0582b80c60fb159846f9615c7952b3c405265955392d77b16d7cfac9e8c5f2c680686e526b412ab8b4356ef9ecd07977764c31db8e02bef40e37b47ac27a
>
> commons-rng-1.0-bin.tar.gz
> e0247ea82aff57cc86ac904ae482c193b7edd5253d26f87fc590b50a738d5fa5c4a6b3b24cd6a48c459e18156ade2588d8c9d12c9a04d15570780240d29ef406
>
> commons-rng-1.0-bin.zip
> f33b922a9d8bc6098bd0e9a98859b17e1cdda21922f136b568868b21af274fdf3d78456a5c73c26c665205a22493836d59b1d33822c4a5c58e82ba64eadcb5e1
>
> commons-rng-1.0-src.tar.gz
> ef4fe63ebbd76e8d95b5f054fed76a40a85f5dd99ca2406a31fb95b593ed3d96b29389bf82424e18895192751689d7590404c8b1d90b28878271c79cad3be18b
>
> commons-rng-1.0-src.zip
>
> The source code contains examples that are not part of the public API.
> These examples contain Java 9 modules and are enabled using a profile
> (see below).
>
> An error when building the Java 9 modules site/javadoc under JDK 11 is a
> known issue as the javadoc command errors when documenting Java 9
> modules that include code from the unamed module.
>
> 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 site' using:
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 1.8.0_222, vendor: Private Build, runtime:
> /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
> "unix"
> ***
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
> /usr/lib/jvm/jdk-11.0.5+10
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
> "unix"
> ***
>
> Java 9 modules in the examples modules.
>
> 'mvn -Pcommons-rng-examples clean install site' using:
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 9, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-9
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
> "unix"
> ***
>
> 'mvn -Pcommons-rng-examples clean install' using:
>
> ***
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T19:41:47+01:00)
> Maven home: /usr/local/apache-maven-3.6.0
> Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
> /usr/lib/jvm/jdk-11.0.5+10
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family:
> "unix"
> ***
>
> Details of changes since 1.2 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/RELEASE-NOTES.txt
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/changes-report.html
>
> Site:
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/index.html
>      (note some *relative* links are broken and the 1.3 directories are
> not yet created - these will be OK once the site is deployed.)
>
> CLIRR Report (compared to 1.2):
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-client-api/clirr-report.html
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-core/clirr-report.html
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-simple/clirr-report.html
>
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-sampling/clirr-report.html
>
> RAT Report:
> https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/rat-report.html
>
> KEYS:
>    https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
>
>    [ ] +1 Release these artifacts
>    [ ] +0 OK, but...
>    [ ] -0 OK, but really should fix...
>    [ ] -1 I oppose this release because...
>
> Thank you,
>
> Alex Herbert,
> Release Manager (using key BC87A3FD0A54480F0BADBEBD21939FF0CA2A6567)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==============================
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-rng.git --branch
> RNG_1_3_RC1 commons-rng-1.3-RC1
> cd commons-rng-1.3-RC1
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which
> you then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Older components still use Apache Clirr:
>
> This step is not required if the site includes a Clirr report page which
> you then must check.
>
> mvn clirr:check
>
> JApiCmp is not used in this component.
>
>
> 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
>
> -the end-
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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

[Gilles Sadowski <gi...@gmail.com>]

Hi.

Le mar. 5 nov. 2019 à 17:36, Alex Herbert <ah...@apache.org> a écrit :
>
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons RNG 1.2 was released, so I would like to release
> Apache Commons RNG 1.3.
>
> Apache Commons RNG 1.3 RC1 is available for review here:
>    https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/
>    https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/
>
> Tag name:
>    RNG_1_3_RC1 (signature can be checked from git using 'git tag -v
> RNG_1_3_RC1')
>
> Tag URL:
> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=43f290e68c31e5bea6cde97c7e999c2e1f2562b2
>
> Commit ID the tag points at:
>    43f290e68c31e5bea6cde97c7e999c2e1f2562b2
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1476/org/apache/commons/
>
> These are the artifacts and their SHA 512 hashes:
> 310c0582b80c60fb159846f9615c7952b3c405265955392d77b16d7cfac9e8c5f2c680686e526b412ab8b4356ef9ecd07977764c31db8e02bef40e37b47ac27a
> commons-rng-1.0-bin.tar.gz
> e0247ea82aff57cc86ac904ae482c193b7edd5253d26f87fc590b50a738d5fa5c4a6b3b24cd6a48c459e18156ade2588d8c9d12c9a04d15570780240d29ef406
> commons-rng-1.0-bin.zip
> f33b922a9d8bc6098bd0e9a98859b17e1cdda21922f136b568868b21af274fdf3d78456a5c73c26c665205a22493836d59b1d33822c4a5c58e82ba64eadcb5e1
> commons-rng-1.0-src.tar.gz
> ef4fe63ebbd76e8d95b5f054fed76a40a85f5dd99ca2406a31fb95b593ed3d96b29389bf82424e18895192751689d7590404c8b1d90b28878271c79cad3be18b
> commons-rng-1.0-src.zip
>
> [...]
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
>
    [X] +1 Release these artifacts
>    [ ] +0 OK, but...
>    [ ] -0 OK, but really should fix...
>    [ ] -1 I oppose this release because...
>

Thanks,
Gilles

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