date:20190313

Re: [imaging] please push site (where did the javadoc scm-publish go?)

2019-03-13 Thread Bruno P. Kinoshita

 Hi Bernd,
Thanks for the fixes. I've followed the instructions here 
https://commons.apache.org/site-publish.html
And it looks like the latest version has been published successfully.
CheersBruno

On Wednesday, 13 March 2019, 1:23:13 pm NZDT, Bernd Eckenfels 
 wrote:  
 
 Hello,

I fixed a gitbox link and modernized the download-page xdoc files (from 
download-page plugin and Manual changes to sha256, see other thread).

Can somebody please push this site update – I dont trust my toolchain at the 
moment.

Speaking of trusting toolchain: while I tried out the site generation it Looks 
like the javadoc was published by svn invocation.

I can however not find where that ended up, I susect ist some staging on the 
cms-site?

It has not materialized in 
 
https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-imaging";
or 
 https://svn.apache.org/repos/asf/commons/cms-site/trunk/

I guess in case it landed somewhere it will get overwritten when you publish 
Imaging again.

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Re: [Rng] New XoShiRo generators

2019-03-13 Thread Alex Herbert


On 13/03/2019 02:20, Gilles Sadowski wrote:

Le mar. 12 mars 2019 à 22:34, Alex Herbert  a écrit :




On 12 Mar 2019, at 17:12, Gilles Sadowski  wrote:

[Replying to list.]

Le mar. 12 mars 2019 à 15:39, Alex Herbert mailto:alex.d.herb...@gmail.com>> a écrit :


On 12/03/2019 15:33, Gilles Sadowski wrote:

Hi Alex.

Le mar. 12 mars 2019 à 12:53, Alex Herbert  a écrit :

On 11/03/2019 23:44, Gilles Sadowski wrote:

Hello.

Le jeu. 7 mars 2019 à 00:44, Alex Herbert  a écrit :

On 6 Mar 2019, at 22:57, Gilles Sadowski  wrote:

However I will test if XorShift1024Star and XorShift1024StarPhi are correlated 
just for completeness.

Did a test of 100 repeats of a correlation of 50 longs from the 
XorShift1024Star and XorShift1024StarPhi, new seed each time:

SummaryStatistics:
n: 100
min: -0.30893547071559685
max: 0.37616626218398586
sum: 3.300079237520435
mean: 0.033000792375204355
geometric mean: NaN
variance: 0.022258533475114764
population variance: 0.022035948140363616
second moment: 2.2035948140363617
sum of squares: 2.312500043775496
standard deviation: 0.14919294043323486
sum of logs: NaN

Note that the algorithm is the same except the final step when the multiplier 
is used to scale the final output long:

   return state[index] * multiplier;

So if it was outputting a double the correlation would be 1. But it is a long 
generator so the long arithmetic wraps to negative on large multiplications. 
The result is that the mean correlation is close to 0.

A single repeat using 1,000,000 numbers has a correlation of 0.002.

Am I missing something here with this type of test?

I'm afraid I don't follow: If the state is the same then I'd assume that
the two generators are the same (i.e. totally correlated).

The state is totally correlated (it is identical). The output sequence is not 
due to wrapping in long arithmetic. Here’s a mock example:

positive number * medium positive number = big positive number (close to 
Long.MAX_VALUE)

Vs

positive number * bigger positive number = negative number (due to wrapping)

So by changing the multiplier this wrapping causes the output bits to be different. 
This is why the new variant "eliminates linear dependencies from one of the 
lowest bits” (quoted from the authors c code).

The multiplier was changed from 1181783497276652981L to 0x9e3779b97f4a7c13L. 
These numbers are big:

Long.MAX_VALUE / 1181783497276652981L = 7.8046207770792755
Long.MAX_VALUE / 0x9e3779b97f4a7c13L = -1.3090169943749475

Big enough such that wrapping will occur on every multiplication unless the positive 
number is <8, or now <2. So basically all the time.

So, IIUC, the output is thus a truncated product formed by the wrapping long 
arithmetic and not correlated.

I wonder: Would that mean that any choice of a "big" number creates a new RNG?
IOW, if we create a composite one from such generators (i.e. pick one
number from
each in order to compose the composite source), will it be as good as
any of them
on the stress test suites?

I don't know. These are the numbers that the authors have come up with
after testing.

Sure. The "TWO_CMRES" variants also results from the author's
experiments.
Some numbers make "good" generators, others not; but that still
does not say whether any two RNGs from the same family are
correlated.  In the case of "TWO_CMRES", the states differ by the
choice of *2* numbers, whereas here we change only one.
So the question is whether it is sufficient.

Perhaps other large numbers are worse.

These numbers are not prime but they are odd:

1181783497276652981L % 769 == 0

0x9e3779b97f4a7c13L == -7046029254386353133

7046029254386353133 % 3 == 0


In the code for SplittableRandom after a split the large value that is
used to add to the state to get the next state is created by a mixing
operation on the current state. Then the bit count is checked to ensure
enough transitions are present:

/**
  * Returns the gamma value to use for a new split instance.
  */
private static long mixGamma(long z) {
 z = (z ^ (z >>> 33)) * 0xff51afd7ed558ccdL; // MurmurHash3 mix
constants
 z = (z ^ (z >>> 33)) * 0xc4ceb9fe1a85ec53L;
 z = (z ^ (z >>> 33)) | 1L;  // force to be odd
 int n = Long.bitCount(z ^ (z >>> 1));   // ensure enough
transitions
 return (n < 24) ? z ^ 0xL : z;
}


So the requirements for a big number may be that it is odd, close to
Long.MAX_VALUE (such that Long.MAX_VALUE / number < 2), and has a lot of
transitions.

What is a "transition"?

A change in the bits from 1 to 0 or 0 to 1 as you move across the binary 
representation.

So for example this has 3 transitions:

0101

I think the point is to avoid numbers that look like this in binary:

110111

(still 3 transitions)

Instead preferring a number that has lots of 0 to 1 flips. Here are the numbers 
we are discussing using Long.toBinaryString(long):

1181783497276652981  
0x1011001101000100111010100010101001001010110110101 =

Re: [Rng] New XoShiRo generators

2019-03-13 Thread Gilles Sadowski

Hello Alex.

Le mer. 13 mars 2019 à 15:37, Alex Herbert  a écrit :
>
> On 13/03/2019 02:20, Gilles Sadowski wrote:
> > Le mar. 12 mars 2019 à 22:34, Alex Herbert  a 
> > écrit :
> >>
> >>
> >>> On 12 Mar 2019, at 17:12, Gilles Sadowski  wrote:
> >>>
> >>> [Replying to list.]
> >>>
> >>> Le mar. 12 mars 2019 à 15:39, Alex Herbert  >>> > a écrit :
> 
>  On 12/03/2019 15:33, Gilles Sadowski wrote:
> 
>  Hi Alex.
> 
>  Le mar. 12 mars 2019 à 12:53, Alex Herbert  a 
>  écrit :
> 
>  On 11/03/2019 23:44, Gilles Sadowski wrote:
> 
>  Hello.
> 
>  Le jeu. 7 mars 2019 à 00:44, Alex Herbert  a 
>  écrit :
> 
>  On 6 Mar 2019, at 22:57, Gilles Sadowski  wrote:
> 
>  However I will test if XorShift1024Star and XorShift1024StarPhi are 
>  correlated just for completeness.
> 
>  Did a test of 100 repeats of a correlation of 50 longs from the 
>  XorShift1024Star and XorShift1024StarPhi, new seed each time:
> 
>  SummaryStatistics:
>  n: 100
>  min: -0.30893547071559685
>  max: 0.37616626218398586
>  sum: 3.300079237520435
>  mean: 0.033000792375204355
>  geometric mean: NaN
>  variance: 0.022258533475114764
>  population variance: 0.022035948140363616
>  second moment: 2.2035948140363617
>  sum of squares: 2.312500043775496
>  standard deviation: 0.14919294043323486
>  sum of logs: NaN
> 
>  Note that the algorithm is the same except the final step when the 
>  multiplier is used to scale the final output long:
> 
> return state[index] * multiplier;
> 
>  So if it was outputting a double the correlation would be 1. But it is a 
>  long generator so the long arithmetic wraps to negative on large 
>  multiplications. The result is that the mean correlation is close to 0.
> 
>  A single repeat using 1,000,000 numbers has a correlation of 0.002.
> 
>  Am I missing something here with this type of test?
> 
>  I'm afraid I don't follow: If the state is the same then I'd assume that
>  the two generators are the same (i.e. totally correlated).
> 
>  The state is totally correlated (it is identical). The output sequence 
>  is not due to wrapping in long arithmetic. Here’s a mock example:
> 
>  positive number * medium positive number = big positive number (close to 
>  Long.MAX_VALUE)
> 
>  Vs
> 
>  positive number * bigger positive number = negative number (due to 
>  wrapping)
> 
>  So by changing the multiplier this wrapping causes the output bits to be 
>  different. This is why the new variant "eliminates linear dependencies 
>  from one of the lowest bits” (quoted from the authors c code).
> 
>  The multiplier was changed from 1181783497276652981L to 
>  0x9e3779b97f4a7c13L. These numbers are big:
> 
>  Long.MAX_VALUE / 1181783497276652981L = 7.8046207770792755
>  Long.MAX_VALUE / 0x9e3779b97f4a7c13L = -1.3090169943749475
> 
>  Big enough such that wrapping will occur on every multiplication unless 
>  the positive number is <8, or now <2. So basically all the time.
> 
>  So, IIUC, the output is thus a truncated product formed by the wrapping 
>  long arithmetic and not correlated.
> 
>  I wonder: Would that mean that any choice of a "big" number creates a 
>  new RNG?
>  IOW, if we create a composite one from such generators (i.e. pick one
>  number from
>  each in order to compose the composite source), will it be as good as
>  any of them
>  on the stress test suites?
> 
>  I don't know. These are the numbers that the authors have come up with
>  after testing.
> 
>  Sure. The "TWO_CMRES" variants also results from the author's
>  experiments.
>  Some numbers make "good" generators, others not; but that still
>  does not say whether any two RNGs from the same family are
>  correlated.  In the case of "TWO_CMRES", the states differ by the
>  choice of *2* numbers, whereas here we change only one.
>  So the question is whether it is sufficient.
> 
>  Perhaps other large numbers are worse.
> 
>  These numbers are not prime but they are odd:
> 
>  1181783497276652981L % 769 == 0
> 
>  0x9e3779b97f4a7c13L == -7046029254386353133
> 
>  7046029254386353133 % 3 == 0
> 
> 
>  In the code for SplittableRandom after a split the large value that is
>  used to add to the state to get the next state is created by a mixing
>  operation on the current state. Then the bit count is checked to ensure
>  enough transitions are present:
> 
>  /**
>    * Returns the gamma value to use for a new split instance.
>    */
>  private static long mixGamma(long z) {
>   z = (z ^ (z >>> 33)) * 0xff51afd7ed558ccdL; // MurmurHash3 mix
> >

[ANNOUNCE] Commons Release Plugin 1.6 released.

2019-03-13 Thread Rob Tompkins

[This announcement is only going to the dev list.]

The Apache Commons Release Plugin team is pleased to announce the release of 
Apache
Commons Release Plugin 1.6.

The Apache Commons Release Plugin is a collection of Java based Maven mojos for
Apache Commons
Release process. These mojos are intended to be used as a collection of steps to
be strung
together for the purpose of removing the manual steps required to produce an
Apache Commons Release.

List of changes:
http://commons.apache.org/commons-release-plugin/changes-report.html

For complete information on Apache Commons Release Plugin, including
instructions
on how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons
Release Plugin website:

http://commons.apache.org/commons-release-plugin/index.html

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

Re: [LAZY][VOTE] Release Apache Commons Build Plugin Maven Mojo 1.10 based on RC2

2019-03-13 Thread Rob Tompkins

Here’s my +1.

> On Mar 9, 2019, at 8:33 PM, Rob Tompkins  wrote:
> 
> We have fixed quite a few bugs and added some significant enhancements since 
> Apache Commons Build Plugin Maven Mojo 1.9 was released, so I would like to 
> release Apache Commons Build Plugin Maven Mojo 1.10.
> 
> Apache Commons Build Plugin Maven Mojo 1.10 RC2 is available for review here:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2 
> (svn revision 32839)
> 
> The Git tag commons-commons-build-plugin-1.10-RC2 commit for this RC is 
> 5f477eeb76bfc16dd2d31f9b75bb9d6ebd7a1b52 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-build-plugin.git;a=commit;h=5f477eeb76bfc16dd2d31f9b75bb9d6ebd7a1b52
> 
> You may checkout this tag using:
>git clone https://gitbox.apache.org/repos/asf/commons-build-plugin.git 
> --branch commons-build-plugin-1.10-RC2
> 
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1429/org/apache/commons/commons-build-plugin/1.10/
> 
> These are the Maven artifacts and their hashes in Nexus:
> 
> #Nexus SHA-1s
> commons-build-plugin-1.10-test-sources.jar=97da2d6f0c62bf642b8b0cf9df6d61a5bdb62fc2
> commons-build-plugin-1.10-tests.jar=b01907ddb6d583b09df81495acb5a3e2be0b9aad
> commons-build-plugin-1.10.pom=38dc8559c1bb27403dd890129d9b49a9c6029121
> commons-build-plugin-1.10-javadoc.jar=e26f2a445e4a4f53af780a90387bf5db09b4490e
> commons-build-plugin-1.10-sources.jar=4abdf023528f9f0770d7354813685e7c683c8e3b
> commons-build-plugin-1.10.jar=f706a99f061f3049fd9407dc04e97ad5b1314df1
> 
> #Release SHA-512s
> #Sat Mar 09 16:48:03 EST 2019
> commons-build-plugin-1.10-src-zip=79bd2b1dc5ba2cedb365d9ef796034b7a418ab4712aebb8ffd702f9619367c45c20bc436fca21b5aa9524568203af7962f6ecdb3a45fcfbc21c20c57291b06dd
> commons-build-plugin-1.10-src-tar.gz=0edb983308812b2bf94611086ba3585a4453ba10a03359bbaedd1a1e4233a8f066d849a51914b29e8332db8afc3e3eb5163d0bebeb65560f6ca439d01daa29fc
> 
> 
> 
> I have tested this with 'mvn clean install site' using: 
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T14:41:47-04:00)
> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.3", arch: "x86_64", family: "mac"
> 
> 
> Details of changes since 1.9 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2/site/changes-report.html
> 
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2/site
>(note some *relative* links are broken and the 1.10 directories are not 
> yet created - these will be OK once the site is deployed.)
> 
> CLIRR Report (compared to 1.9):
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2/site/clirr-report.html
> 
> JApiCmp Report (compared to 1.9):
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2/site/japicmp.html
> 
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2/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,
> 
> Rob Tompkins, 
> Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314)
> 
> 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:
> 
> git clone https://gitbox.apache.org/repos/asf/commons-build-plugin.git -b 
> commons-commons-build-plugin-1.10-RC2
> cd commons-commons-build-plugin-1.10-RC2
> 
> 2) Check Apache licenses:
> 
> mvn apache-rat:check
> 
> 3) Build the package:
> 
> mvn -V clean package
> 
> You can record the Maven and Java version produced by -V in your VOTE reply.
> 
> 4) Build the site for a single module project:
> 
> mvn site
> Check the site reports in:
> target\site\index.html
> 
> 4) Build the site for a multi-module project:
> 
> mvn site
> mvn site:stage
> Check the site reports in:
> target\site\index.html
> 


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

[RESULT][LAZY][VOTE] Release Apache Commons Build Plugin Maven Mojo 1.10 based on RC2

2019-03-13 Thread Rob Tompkins

This vote passes with the following votes:

Gary Gregory: +1,
Rob Tompkins: +1, and

no -1 votes. I will proceed with promoting the release.

All the best,
-Rob

> On Mar 9, 2019, at 8:33 PM, Rob Tompkins  wrote:
> 
> We have fixed quite a few bugs and added some significant enhancements since 
> Apache Commons Build Plugin Maven Mojo 1.9 was released, so I would like to 
> release Apache Commons Build Plugin Maven Mojo 1.10.
> 
> Apache Commons Build Plugin Maven Mojo 1.10 RC2 is available for review here:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2 
> (svn revision 32839)
> 
> The Git tag commons-commons-build-plugin-1.10-RC2 commit for this RC is 
> 5f477eeb76bfc16dd2d31f9b75bb9d6ebd7a1b52 which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-build-plugin.git;a=commit;h=5f477eeb76bfc16dd2d31f9b75bb9d6ebd7a1b52
> 
> You may checkout this tag using:
>git clone https://gitbox.apache.org/repos/asf/commons-build-plugin.git 
> --branch commons-build-plugin-1.10-RC2
> 
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1429/org/apache/commons/commons-build-plugin/1.10/
> 
> These are the Maven artifacts and their hashes in Nexus:
> 
> #Nexus SHA-1s
> commons-build-plugin-1.10-test-sources.jar=97da2d6f0c62bf642b8b0cf9df6d61a5bdb62fc2
> commons-build-plugin-1.10-tests.jar=b01907ddb6d583b09df81495acb5a3e2be0b9aad
> commons-build-plugin-1.10.pom=38dc8559c1bb27403dd890129d9b49a9c6029121
> commons-build-plugin-1.10-javadoc.jar=e26f2a445e4a4f53af780a90387bf5db09b4490e
> commons-build-plugin-1.10-sources.jar=4abdf023528f9f0770d7354813685e7c683c8e3b
> commons-build-plugin-1.10.jar=f706a99f061f3049fd9407dc04e97ad5b1314df1
> 
> #Release SHA-512s
> #Sat Mar 09 16:48:03 EST 2019
> commons-build-plugin-1.10-src-zip=79bd2b1dc5ba2cedb365d9ef796034b7a418ab4712aebb8ffd702f9619367c45c20bc436fca21b5aa9524568203af7962f6ecdb3a45fcfbc21c20c57291b06dd
> commons-build-plugin-1.10-src-tar.gz=0edb983308812b2bf94611086ba3585a4453ba10a03359bbaedd1a1e4233a8f066d849a51914b29e8332db8afc3e3eb5163d0bebeb65560f6ca439d01daa29fc
> 
> 
> 
> I have tested this with 'mvn clean install site' using: 
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T14:41:47-04:00)
> Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.3", arch: "x86_64", family: "mac"
> 
> 
> Details of changes since 1.9 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2/site/changes-report.html
> 
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2/site
>(note some *relative* links are broken and the 1.10 directories are not 
> yet created - these will be OK once the site is deployed.)
> 
> CLIRR Report (compared to 1.9):
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2/site/clirr-report.html
> 
> JApiCmp Report (compared to 1.9):
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2/site/japicmp.html
> 
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-build-plugin/1.10-RC2/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,
> 
> Rob Tompkins, 
> Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314)
> 
> 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:
> 
> git clone https://gitbox.apache.org/repos/asf/commons-build-plugin.git -b 
> commons-commons-build-plugin-1.10-RC2
> cd commons-commons-build-plugin-1.10-RC2
> 
> 2) Check Apache licenses:
> 
> mvn apache-rat:check
> 
> 3) Build the package:
> 
> mvn -V clean package
> 
> You can record the Maven and Java version produced by -V in your VOTE reply.
> 
> 4) Build the site for a single module project:
> 
> mvn site
> Check the site reports in:
> target\site\index.html
> 
> 4) Build the site for a multi-module project:
> 
> mvn site
> mvn site:stage
> Check the site reports in:
> target\site\index.html
> 


-
To unsubscribe, e-mail:

Re: [ANNOUNCE] Commons Release Plugin 1.6 released.

2019-03-13 Thread Bruno P. Kinoshita

 Was waiting for the release before start working on imaging RC3.
Thanks Rob!
Bruno


On Thursday, 14 March 2019, 2:17:43 pm NZDT, Rob Tompkins 
 wrote:  
 
 [This announcement is only going to the dev list.]

The Apache Commons Release Plugin team is pleased to announce the release of 
Apache
Commons Release Plugin 1.6.

The Apache Commons Release Plugin is a collection of Java based Maven mojos for
Apache Commons
Release process. These mojos are intended to be used as a collection of steps to
be strung
together for the purpose of removing the manual steps required to produce an
Apache Commons Release.

List of changes:
http://commons.apache.org/commons-release-plugin/changes-report.html

For complete information on Apache Commons Release Plugin, including
instructions
on how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons
Release Plugin website:

http://commons.apache.org/commons-release-plugin/index.html

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

Re: [ANNOUNCE] Commons Release Plugin 1.6 released.

2019-03-13 Thread Rob Tompkins

No worries. The main way to run things when you do a promotion is:

mvn -Duser.name= -Prelease clean commons-release:clean-staging 
test package site deploy

or for dry run:

mvn -Duser.name= -Prelease -Ptest-deploy clean 
commons-release:clean-staging test package site deploy

doing this should clean up the dist.apache.org  dev 
staging directory if there’s anything there when you start the staging process.

-Rob

> On Mar 13, 2019, at 9:20 PM, Bruno P. Kinoshita  wrote:
> 
> Was waiting for the release before start working on imaging RC3.
> Thanks Rob!
> Bruno
> 
> 
>On Thursday, 14 March 2019, 2:17:43 pm NZDT, Rob Tompkins 
>  wrote:  
> 
> [This announcement is only going to the dev list.]
> 
> The Apache Commons Release Plugin team is pleased to announce the release of 
> Apache
> Commons Release Plugin 1.6.
> 
> The Apache Commons Release Plugin is a collection of Java based Maven mojos 
> for
> Apache Commons
> Release process. These mojos are intended to be used as a collection of steps 
> to
> be strung
> together for the purpose of removing the manual steps required to produce an
> Apache Commons Release.
> 
> List of changes:
> http://commons.apache.org/commons-release-plugin/changes-report.html
> 
> For complete information on Apache Commons Release Plugin, including
> instructions
> on how to submit bug reports,
> patches, or suggestions for improvement, see the Apache Apache Commons
> Release Plugin website:
> 
> http://commons.apache.org/commons-release-plugin/index.html
> 
> Cheers,
> -Rob
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org

Re: [imaging] please push site (where did the javadoc scm-publish go?)

Re: [Rng] New XoShiRo generators

Re: [Rng] New XoShiRo generators

[ANNOUNCE] Commons Release Plugin 1.6 released.

Re: [LAZY][VOTE] Release Apache Commons Build Plugin Maven Mojo 1.10 based on RC2

[RESULT][LAZY][VOTE] Release Apache Commons Build Plugin Maven Mojo 1.10 based on RC2

Re: [ANNOUNCE] Commons Release Plugin 1.6 released.

Re: [ANNOUNCE] Commons Release Plugin 1.6 released.

8 matches

Site Navigation

Mail list logo

Footer information