[VOTE] Release Apache Commons RNG 1.3 based on RC1

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VOTE] Release Apache Commons RNG 1.3 based on RC1

Alex Herbert-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski-2
Hi.

Le mar. 5 nov. 2019 à 17:36, Alex Herbert <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Pascal Schumacher
In reply to this post by Alex Herbert-2
+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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Alex Herbert
In reply to this post by Alex Herbert-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Alex Herbert
In reply to this post by Alex Herbert-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

garydgregory
In reply to this post by Alex Herbert-2
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

Alex Herbert
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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Alex Herbert

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 <[hidden email]>
>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

garydgregory
In reply to this post by Alex Herbert
I usually run site builds with -P jacoco and -P japicmp

Gary

On Mon, Nov 11, 2019 at 12:55 PM Alex Herbert <[hidden email]>
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 <[hidden email]>
> 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski-2
In reply to this post by Alex Herbert
Hello.

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

Yes.

Gilles

> [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski-2
In reply to this post by Alex Herbert
> > [...]
> >
> > 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Alex Herbert


> On 11 Nov 2019, at 18:36, Gilles Sadowski <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski-2
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 <[hidden email]>:

>
>
>> On 11 Nov 2019, at 18:36, Gilles Sadowski <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Alex Herbert


> On 11 Nov 2019, at 23:40, Gilles Sadowski <[hidden email]> 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 <[hidden email]>:
>>
>>
>>> On 11 Nov 2019, at 18:36, Gilles Sadowski <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski-2
2019-11-12 2:28 UTC+01:00, Alex Herbert <[hidden email]>:

>
>
>> On 11 Nov 2019, at 23:40, Gilles Sadowski <[hidden email]> 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 <[hidden email]>:
>>>
>>>
>>>> On 11 Nov 2019, at 18:36, Gilles Sadowski <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Alex Herbert

On 12/11/2019 09:06, Gilles Sadowski wrote:

> 2019-11-12 2:28 UTC+01:00, Alex Herbert <[hidden email]>:
>>
>>> On 11 Nov 2019, at 23:40, Gilles Sadowski <[hidden email]> 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 <[hidden email]>:
>>>>
>>>>> On 11 Nov 2019, at 18:36, Gilles Sadowski <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski-2
Hello Alex.

Le mar. 12 nov. 2019 à 16:15, Alex Herbert <[hidden email]> a écrit :

>
>
> On 12/11/2019 09:06, Gilles Sadowski wrote:
> > 2019-11-12 2:28 UTC+01:00, Alex Herbert <[hidden email]>:
> >>
> >>> On 11 Nov 2019, at 23:40, Gilles Sadowski <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Alex Herbert


> On 12 Nov 2019, at 15:39, Gilles Sadowski <[hidden email]> wrote:
>
> Hello Alex.
>
> Le mar. 12 nov. 2019 à 16:15, Alex Herbert <[hidden email] <mailto:[hidden email]>> a écrit :
>>
>>
>> On 12/11/2019 09:06, Gilles Sadowski wrote:
>>> 2019-11-12 2:28 UTC+01:00, Alex Herbert <[hidden email]>:
>>>>
>>>>> On 11 Nov 2019, at 23:40, Gilles Sadowski <[hidden email]> 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: [hidden email] <mailto:[hidden email]>
> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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

Alex Herbert


> On 12 Nov 2019, at 16:41, Alex Herbert <[hidden email]> wrote:
>
>
>
>> On 12 Nov 2019, at 15:39, Gilles Sadowski <[hidden email] <mailto:[hidden email]>> wrote:
>>
>> Hello Alex.
>>
>> Le mar. 12 nov. 2019 à 16:15, Alex Herbert <[hidden email] <mailto:[hidden email]>> a écrit :
>>>
>>>
>>> On 12/11/2019 09:06, Gilles Sadowski wrote:
>>>> 2019-11-12 2:28 UTC+01:00, Alex Herbert <[hidden email] <mailto:[hidden email]>>:
>>>>>
>>>>>> On 11 Nov 2019, at 23:40, Gilles Sadowski <[hidden email] <mailto:[hidden email]>> 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: [hidden email] <mailto:[hidden email]>
>> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski-2
In reply to this post by Alex Herbert
Hello.

Le mar. 12 nov. 2019 à 17:41, Alex Herbert <[hidden email]> a écrit :

>
>
>
> > On 12 Nov 2019, at 15:39, Gilles Sadowski <[hidden email]> wrote:
> >
> > Hello Alex.
> >
> > Le mar. 12 nov. 2019 à 16:15, Alex Herbert <[hidden email] <mailto:[hidden email]>> a écrit :
> >>
> >>
> >> On 12/11/2019 09:06, Gilles Sadowski wrote:
> >>> 2019-11-12 2:28 UTC+01:00, Alex Herbert <[hidden email]>:
> >>>>
> >>>>> On 11 Nov 2019, at 23:40, Gilles Sadowski <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

12