Re: [Vote] Release Apache Commons RNG v1.2 (RC1)
On Tue, 4 Dec 2018 09:11:44 -0500, Rob Tompkins wrote: I’ll try to get to validation on this by the end of the day, Thanks! unless @Gilles, you want to take into account the vote below. I don't think anything mentioned is blocking (cf. my answer in the other post). [Hmm, it mostly stems from the release-plugin not being robust yet when applied to a multi-module project, missing (cf. generated "vote.txt") or unexpected conditions (it uses default values where it shouldn't). It also lacks reporting adequate error messages when something goes wrong like SVN authentication (1.5-SNAPSHOT is better!).]. So, please, do review the contents of the official release. Regards, Gilles -Rob On Dec 4, 2018, at 9:08 AM, Alex Herbert wrote: +0 (non-binding) The user guide shows updated Performance and Quality tables following the changes to the core implementation for all tables (verses release 1.1). I note that the times for the BoxMullerNormalizedGaussianSampler have all improved nearly 2-fold which is strange. The code appears to be unchanged from v1.1. The RC site: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC1/site/userguide/rng.html Is also showing at the official location: http://commons.apache.org/proper/commons-rng/ This link is broken from the 'Release History' page: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC1/site/release-notes/RELEASE-NOTES-1.2.txt The following reports are empty in the Project Reports menu: - Surefire Report - japicmp - JaCoCo Aggregate (this link jumps out of the 'frames' view an loses the menu) - Checkstyle There are no spotbugs or PMD entries in the menu. I'm not sure where to get the artifacts to check the hashes so I've not done that. The 'Project Documentation > Source Code Management' page states to use: git clone http://git-wip-us.apache.org/repos/asf/commons-rng.git This doesn't work for me. I used the mirror and the RC tag: https://github.com/apache/commons-rng Building with mvn verify site Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T19:33:14+01:00) Maven home: /usr/local/apache-maven-3.5.4 Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk-amd64/jre Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-139-generic", arch: "amd64", family: "unix" This works but the local site is missing the same Project Reports. The modules all have surefire reports, PMD, CPD, spotbugs, checkstyle in the target directories. Not sure where japicmp writes plain results but the japicmp.html page is always blank. So something is broken with aggregating the reports and possibly the japicmp report. Alex On 04/12/2018 01:19, Gilles wrote: Hello. I would like to release Apache Commons RNG v1.2. Apache Commons RNG 1.2 RC1 is available for review: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC1 (svn revision 31333) The Git tag for this RC is "RNG_1_2_RC1": https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=tag;h=refs/tags/RNG_1_2_RC1 Maven artifacts: https://repository.apache.org/content/repositories/orgapachecommons-1397/org/apache/commons/ Maven artifacts' SHA-512 hashes in Nexus: commons-rng-1.2-bin-tar.gz=beba8312f8702563b7d2a8b3919e812b60e509342fb102274b1fef8107c67d8419b74a82b7c6fd6fdfd9ed03cd590751a80ca27614cca2a909ba057e3c513ef7 commons-rng-1.2-bin-tar.gz.asc=500c67f4c3c1fdc6583fab068f20664e7235e5f983dcc90c1c9d70290bf5eb3e4a76d7fb3eba56f4a3e8e957bf0c490db237698419c95e2dbca8716f393def4c commons-rng-1.2-src-tar.gz=a9325efec521ff3f3489fa67568bc91b5a89014c888d81d14a39e669cf678648ba60722e3f3320ad643d9e84ef3193f272bfd78b4495044b6a763a6442590a3f commons-rng-1.2-bin-zip=55342112a7e505882ad5739233508d2957c396f71bf22a45226844bf5ccdfb4947066a0fb111f1a51287ef359bdd1e84f9c7fdde7c3a02092b4cf45aa9eb3d99 commons-rng-1.2-src-zip=f2d7dbabb1479afd15adae00e9007480638d7c8b5a2900d1d43ec7497efd8f2a0a66bc84032c642de6b3ecf0829a01d3c6748e583b43476f4f3647fe2292 commons-rng-1.2-src-zip.asc=e931a42202b3ba274ca07251d8114066c88085014823c421b0cba15c300596aad1d7a7c7f42f85fe0e62cfa3ab4dd4a7afd32ab18149d42e5e775c9c2bf0e187 commons-rng-1.2-pom.asc=4c9ebbb00fbc1b7f7a679c1f165fc6561ad69fd5e7ec2b268d89c26053643a9574ac69876d47cc8e1a27f595010a6466c4f679518ee7dec5b9c250a5a4720089 commons-rng-1.2-bin-zip.asc=30e72114890ad6551fb2dc21251d787cf7410d22c92960375d2bfc8586279d1981261af74ce9477313bd1dac4ee632d94100c0db6340a216e385c947b491f432 commons-rng-1.2-src-tar.gz.asc=e1a04875744dc3cd5b04bfbe5c6fa52e553ecc645c5923db53259202daf28f5fd8570c84a9fcb0ae10669a0924101d4d737ca23fb9cbcd4da7f708ce67c6b5f8 Details of changes: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC1/site/changes-report.h
Re: [Vote] Release Apache Commons RNG v1.2 (RC1)
On Tue, 4 Dec 2018 16:33:48 +, Alex Herbert wrote: On 04/12/2018 15:15, Gilles wrote: On Tue, 4 Dec 2018 14:08:59 +, Alex Herbert wrote: +0 (non-binding) The user guide shows updated Performance and Quality tables following the changes to the core implementation for all tables (verses release 1.1). I note that the times for the BoxMullerNormalizedGaussianSampler have all improved nearly 2-fold which is strange. Agreed. But I can't say much more. You are welcome to confirm that either the current or the previous values (or neither) are correct. And we'll update the site accordingly. OK. I ran a quick trial of SamplersPerformance and it seems that the BoxMullerNormalizedGaussianSampler should be slower than the others. This matches the old results. commons-rng/commons-rng-examples/examples-jmh > mvn -P benchmark '-Dbenchmark=org.apache.commons.rng.examples.jmh.distribution.(Next*|SamplersPerformance.*Gaussian.*)' test Here are the results with 5 iterations: RNG BoxMuller Marsaglia Ziggurat ISAAC 0.95078383140.53942851440.2749968235 JDK 1.06886825960.64403177650.3243021893 KISS0.98582366180.47000588580.2568217134 MT 1.02754243890.52687593590.2690456029 MT_64 0.88268167070.45571044780.2296754309 MWC_256 0.95075223530.41963833020.2114958789 SPLIT_MIX_640.83773824440.36173037090.1846275404 TWO_CMRES 0.85361553680.387562567 0.1884355236 WELL_1024_A 1.08558152540.59940466780.3088309612 WELL_19937_A1.13505483350.67183046850.3952235947 WELL_19937_C1.15183941420.69857434970.419527361 WELL_44497_A1.15351286580.69582940480.4177399342 WELL_44497_B1.16790612630.72375242430.4451146416 WELL_512_A 1.05796049220.58138590040.2975178907 XOR_SHIFT_1024_S0.84054573680.37659780360.2007193048 I'll run the benchmark with more iterations... I was in fact running Java 10 for the benchmarks: "BoxMuller" is indeed 50% faster on it than on Java 8 and "Marsaglia" 10% slower! Thanks for the clarifications about the reports being in the modules. It is not obvious from the site. Now I've found them they look OK. So, you'll change your vote? Regards, Gilles They are next to the files, here: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC1/binaries/ and here: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC1/source/ Downloaded and checked with gpg and sha512sum. All OK. The 'Project Documentation > Source Code Management' page states to use: git clone http://git-wip-us.apache.org/repos/asf/commons-rng.git Odd. It works for me (TM). :-) It now works for me too. The command to generate the full site for a multi-module project is $ mvn clean site site:stage Now I've found the module reports the local build looks good too. Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Amazon Corretto
On Wed, 14 Nov 2018 10:33:34 -0800, Eric Barnhill wrote: It reminds me uncomfortably of Microsoft's old "embrace, extend, exterminate" philosophy in the 1990s. https://www.linuxjournal.com/video/linux-sucks-forever On Wed, Nov 14, 2018 at 10:03 AM Pascal Schumacher wrote: Isn't this basically the same as Adopt Open JDK: https://adoptopenjdk.net or am I missing something? -Pascal Am 14.11.2018 um 15:14 schrieb Rob Tompkins: > Curious to see what people’s thoughts are to this: > > https://aws.amazon.com/corretto/ > > -Rob - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Vote] Release Apache Commons RNG v1.2 (RC1)
On Wed, 5 Dec 2018 21:29:26 -0500, Rob Tompkins wrote:
With:
$ mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T14:33:14-04:00)
Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 9.0.4, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.1", arch: "x86_64", family:
"mac"
I get this:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site)
on project commons-rng-sampling: Error generating
maven-javadoc-plugin:3.0.1:javadoc report:
[ERROR] Exit code: 1 -
/Users/tompkicr/Desktop/commons-rng/source/commons-rng-1.2-src/commons-rng-sampling/src/main/java/org/apache/commons/rng/sampling/distribution/SmallMeanPoissonSampler.java:35:
error: reference not found
[ERROR] * For large means, {@link LargePoissonSampler} should be
used instead.
This is a type in the Javadoc (should have been
"LargeMeanPoissonSampler", fixed now).
In my environment, it only triggered a warning.
Does the policy consider this as a blocker?
Gilles
[ERROR]^
[ERROR]
[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home/bin/javadoc
@options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'/Users/tompkicr/Desktop/commons-rng/source/commons-rng-1.2-src/commons-rng-sampling/target/site/apidocs'
dir.
On Dec 3, 2018, at 8:19 PM, Gilles
wrote:
Hello.
I would like to release Apache Commons RNG v1.2.
Apache Commons RNG 1.2 RC1 is available for review:
https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC1 (svn
revision 31333)
The Git tag for this RC is "RNG_1_2_RC1":
https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=tag;h=refs/tags/RNG_1_2_RC1
Maven artifacts:
https://repository.apache.org/content/repositories/orgapachecommons-1397/org/apache/commons/
Maven artifacts' SHA-512 hashes in Nexus:
commons-rng-1.2-bin-tar.gz=beba8312f8702563b7d2a8b3919e812b60e509342fb102274b1fef8107c67d8419b74a82b7c6fd6fdfd9ed03cd590751a80ca27614cca2a909ba057e3c513ef7
commons-rng-1.2-bin-tar.gz.asc=500c67f4c3c1fdc6583fab068f20664e7235e5f983dcc90c1c9d70290bf5eb3e4a76d7fb3eba56f4a3e8e957bf0c490db237698419c95e2dbca8716f393def4c
commons-rng-1.2-src-tar.gz=a9325efec521ff3f3489fa67568bc91b5a89014c888d81d14a39e669cf678648ba60722e3f3320ad643d9e84ef3193f272bfd78b4495044b6a763a6442590a3f
commons-rng-1.2-bin-zip=55342112a7e505882ad5739233508d2957c396f71bf22a45226844bf5ccdfb4947066a0fb111f1a51287ef359bdd1e84f9c7fdde7c3a02092b4cf45aa9eb3d99
commons-rng-1.2-src-zip=f2d7dbabb1479afd15adae00e9007480638d7c8b5a2900d1d43ec7497efd8f2a0a66bc84032c642de6b3ecf0829a01d3c6748e583b43476f4f3647fe2292
commons-rng-1.2-src-zip.asc=e931a42202b3ba274ca07251d8114066c88085014823c421b0cba15c300596aad1d7a7c7f42f85fe0e62cfa3ab4dd4a7afd32ab18149d42e5e775c9c2bf0e187
commons-rng-1.2-pom.asc=4c9ebbb00fbc1b7f7a679c1f165fc6561ad69fd5e7ec2b268d89c26053643a9574ac69876d47cc8e1a27f595010a6466c4f679518ee7dec5b9c250a5a4720089
commons-rng-1.2-bin-zip.asc=30e72114890ad6551fb2dc21251d787cf7410d22c92960375d2bfc8586279d1981261af74ce9477313bd1dac4ee632d94100c0db6340a216e385c947b491f432
commons-rng-1.2-src-tar.gz.asc=e1a04875744dc3cd5b04bfbe5c6fa52e553ecc645c5923db53259202daf28f5fd8570c84a9fcb0ae10669a0924101d4d737ca23fb9cbcd4da7f708ce67c6b5f8
Details of changes:
https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC1/RELEASE-NOTES.txt
https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC1/site/changes-report.html
Site:
http://commons.apache.org/proper/commons-rng/
KEYS:
id=B39617E095CD748DFE505816703413011E22D5B8
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...
Thanks,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Vote] Release Apache Commons RNG v1.2 (RC1)
On Thu, 6 Dec 2018 11:37:25 +, sebb wrote:
On Thu, 6 Dec 2018 at 10:58, Gilles
wrote:
On Wed, 5 Dec 2018 21:29:26 -0500, Rob Tompkins wrote:
> With:
>
> $ mvn -version
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T14:33:14-04:00)
> Maven home: /usr/local/Cellar/maven/3.5.4/libexec
> Java version: 9.0.4, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.1", arch: "x86_64", family:
> "mac"
>
> I get this:
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.7.1:site
(default-site)
> on project commons-rng-sampling: Error generating
> maven-javadoc-plugin:3.0.1:javadoc report:
> [ERROR] Exit code: 1 -
>
>
/Users/tompkicr/Desktop/commons-rng/source/commons-rng-1.2-src/commons-rng-sampling/src/main/java/org/apache/commons/rng/sampling/distribution/SmallMeanPoissonSampler.java:35:
> error: reference not found
> [ERROR] * For large means, {@link LargePoissonSampler} should be
> used instead.
This is a type in the Javadoc (should have been
"LargeMeanPoissonSampler", fixed now).
In my environment, it only triggered a warning.
Does the policy consider this as a blocker?
I don't think Javadoc errors are blockers per se, however a failing
build seems to me like a blocker unless there are extenutating
circumstances.
For example a very rarely used JVM/OS combination.
Whilst it may be tedious to fix this, if we don't, there are likely
to
be ongoing complaints about the issue that will have to be dealt
with,
possibly causing more work overall.
OK. I'll make a new RC.
But the thing is, although we expect support from
automated/reproducible
build (through common maven config), every time we advocate/work
towards
a single way to manage Commons projects, the discussion dies off with
TMTOWTDI.[1]
In my experience, this is what makes it painful to handle releases (for
manager and reviewers alike).[2]
The extenuating circumstance is that we don't want to enforce
convergence
of the release process, and then complain that it is tedious... :-}
Regards,
Gilles
[1] https://en.wiktionary.org/wiki/TMTOWTDI#English
[2] And also the Jenkins configuration (that now seem to break with
every update of the CI system and/or POM upgrade).
[...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[Cancel][Vote] Release Apache Commons RNG v1.2 (RC1)
Preparing RC2. Regards, Gilles On Tue, 04 Dec 2018 02:19:33 +0100, Gilles wrote: Hello. I would like to release Apache Commons RNG v1.2. Apache Commons RNG 1.2 RC1 is available for review: [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Vote] RC2 for releasing Commons RNG v1.2
Hello. I'd like to release version 1.2 of "Commons RNG". Apache Commons RNG v1.2 (RC2) is available for review: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC2 (svn revision 31410) Git tag is named "RNG_1_2_RC2": https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=tag;h=refs/tags/RNG_1_2_RC2 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1399/org/apache/commons/ Maven artifacts' SHA-512 hashes in Nexus: commons-rng-1.2-bin-tar.gz=681530e0f26f1ac84b626de4adfc7a5c615b2784157da412b329c5ff33361a7b commons-rng-1.2-bin-tar.gz.asc=5785291f481029c00600cca402ca37fbf9bea64a1b58db4f58c3c41270200e58 commons-rng-1.2-src-tar.gz=89d1d4fb95651c0d008d941b928e468822769a142f69c1e7f174994e3c13285c commons-rng-1.2-bin-zip=09608ac82e654287d69cca991d516cd95f09189f412bf2be1292f10f9b7d103e commons-rng-1.2-src-zip=aabe2a548c991ef89a7f86a5ed6b7ba9847678a0fd87b48d7d40775ba545063d commons-rng-1.2-src-zip.asc=d676fa86a0fa81db7c9c63fb1c86dc5ae23755081186adf6f3650bee3e341e96 commons-rng-1.2-pom.asc=24d621f1b1724134d4d493e0672e9c9a0627c0e8b5614c3ef4d8030ecc14f541 commons-rng-1.2-bin-zip.asc=243e1b663c639116840301d3610abec9b5d6b68f494eee10b164fc7057b4a7e5 commons-rng-1.2-src-tar.gz.asc=7480a80014b3ec58cf3a98c84bb693ba5ea86b02361889c43893752cd9203f33 Details of changes since 1.1 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC2/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC2/site/changes-report.html Site: http://commons.apache.org/proper/commons-rng/ KEYS: id=B39617E095CD748DFE505816703413011E22D5B8 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... Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Fwd: [NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org
Hi. [See message quoted below.] Any objection to my filing an INFRA request for each of the following components: [Numbers] [RNG] [Statistics] [Math] ? Gilles Original Message Subject: [NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org Date: Fri, 7 Dec 2018 17:52:36 +0100 From: Daniel Gruno To: "us...@infra.apache.org" Reply-To: "us...@infra.apache.org" [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS] Hello Apache projects, I am writing to you because you may have git repositories on the git-wip-us server, which is slated to be decommissioned in the coming months. All repositories will be moved to the new gitbox service which includes direct write access on github as well as the standard ASF commit access via gitbox.apache.org. ## Why this move? ## The move comes as a result of retiring the git-wip service, as the hardware it runs on is longing for retirement. In lieu of this, we have decided to consolidate the two services (git-wip and gitbox), to ease the management of our repository systems and future-proof the underlying hardware. The move is fully automated, and ideally, nothing will change in your workflow other than added features and access to GitHub. ## Timeframe for relocation ## Initially, we are asking that projects voluntarily request to move their repositories to gitbox, hence this email. The voluntary timeframe is between now and January 9th 2019, during which projects are free to either move over to gitbox or stay put on git-wip. After this phase, we will be requiring the remaining projects to move within one month, after which we will move the remaining projects over. To have your project moved in this initial phase, you will need: - Consensus in the project (documented via the mailing list) - File a JIRA ticket with INFRA to voluntarily move your project repos over to gitbox (as stated, this is highly automated and will take between a minute and an hour, depending on the size and number of your repositories) To sum up the preliminary timeline; - December 9th 2018 -> January 9th 2019: Voluntary (coordinated) relocation - January 9th -> February 6th: Mandated (coordinated) relocation - February 7th: All remaining repositories are mass migrated. This timeline may change to accommodate various scenarios. ## Using GitHub with ASF repositories ## When your project has moved, you are free to use either the ASF repository system (gitbox.apache.org) OR GitHub for your development and code pushes. To be able to use GitHub, please follow the primer at: https://reference.apache.org/committer/github We appreciate your understanding of this issue, and hope that your project can coordinate voluntarily moving your repositories in a timely manner. All settings, such as commit mail targets, issue linking, PR notification schemes etc will automatically be migrated to gitbox as well. With regards, Daniel on behalf of ASF Infra. PS:For inquiries, please reply to us...@infra.apache.org, not your project's dev list :-). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Vote] RC2 for releasing Commons RNG v1.2
On Sat, 8 Dec 2018 09:48:22 -0500, Rob Tompkins wrote: +1 (I predicate this on our being ok with a java 9 build only) All modules that compose the official release: client-api core simple sampling compile fine and pass all the tests with Java 8. The "main" code compiles fine with Java 10, but the surefire plugin crashes. I do not have older JDKs at hand (and Jenkins builds broke for some reason not clearly apparent from the console log). clirr - good (2 info issues) I suggest that we consider setting up CP to support the newer https://revapi.org/ rat - good pmd - few nits Those appeared after an upgrade of the tool. On the TODO list: https://issues.apache.org/jira/projects/RNG/issues/RNG-49 checkstyle - good signatures - good build java9 only: $ mvn -version Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T14:33:14-04:00) Maven home: /usr/local/Cellar/maven/3.5.4/libexec Java version: 9.0.4, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.14.1", arch: "x86_64", family: "mac" It was a tad cumbersome working with all of the nexus artifacts for release validation. I'm not sure what you mean here. If it is about the checksum/signature check, I had suggested that it could be automated: After the upload to Nexus, the release plugin should download the artefacts and verify that the signatures are OK. Thanks for the review, Gilles -Rob On Dec 6, 2018, at 12:15 PM, Gilles wrote: Hello. I'd like to release version 1.2 of "Commons RNG". Apache Commons RNG v1.2 (RC2) is available for review: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC2 (svn revision 31410) Git tag is named "RNG_1_2_RC2": https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=tag;h=refs/tags/RNG_1_2_RC2 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1399/org/apache/commons/ Maven artifacts' SHA-512 hashes in Nexus: commons-rng-1.2-bin-tar.gz=681530e0f26f1ac84b626de4adfc7a5c615b2784157da412b329c5ff33361a7b commons-rng-1.2-bin-tar.gz.asc=5785291f481029c00600cca402ca37fbf9bea64a1b58db4f58c3c41270200e58 commons-rng-1.2-src-tar.gz=89d1d4fb95651c0d008d941b928e468822769a142f69c1e7f174994e3c13285c commons-rng-1.2-bin-zip=09608ac82e654287d69cca991d516cd95f09189f412bf2be1292f10f9b7d103e commons-rng-1.2-src-zip=aabe2a548c991ef89a7f86a5ed6b7ba9847678a0fd87b48d7d40775ba545063d commons-rng-1.2-src-zip.asc=d676fa86a0fa81db7c9c63fb1c86dc5ae23755081186adf6f3650bee3e341e96 commons-rng-1.2-pom.asc=24d621f1b1724134d4d493e0672e9c9a0627c0e8b5614c3ef4d8030ecc14f541 commons-rng-1.2-bin-zip.asc=243e1b663c639116840301d3610abec9b5d6b68f494eee10b164fc7057b4a7e5 commons-rng-1.2-src-tar.gz.asc=7480a80014b3ec58cf3a98c84bb693ba5ea86b02361889c43893752cd9203f33 Details of changes since 1.1 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC2/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC2/site/changes-report.html Site: http://commons.apache.org/proper/commons-rng/ KEYS: id=B39617E095CD748DFE505816703413011E22D5B8 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... Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RNG] How to enable japicmp?
Hi. [...] from [Lang].[1] The plugin crashes with NPE. [...] Are there problems with "japicmp" that are specific to multi-modules projects? It seems that's already fixed: https://github.com/siom79/japicmp/issues/210 Thanks for the info. Worth trying with a newer version. Looking at the "commons-parent" project, the upgrade was done (to 0.13) in version 48-SNAPSHOT, which has not been released yet. Regards, Gilles [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Numbers] Inheritance and ValJO ? (Was: Where to define "quaternion"?)
Hello. After the discussion quote below, the conclusion was to go with inheritance: https://issues.apache.org/jira/browse/NUMBERS-80 However, it would make "Quaternion" fail the "ValJO" definition[1] that mandates that all constructors be private. Would a protected constructor really be an issue? [In the case of "Quaternion", the subclass constructor would only perform additional validation (cf. below for details).] Thanks, Gilles [1] https://blog.joda.org/2014/03/valjos-value-java-objects.html On Mon, 03 Dec 2018 10:31:42 +0100, Gilles wrote: Hi. On Mon, 3 Dec 2018 03:56:02 +, Matt Juntunen wrote: I was just thinking from a practical standpoint. My current QuaternionRotation class is still in my working branch for GEOMETRY-14 and so isn't really accessible to anyone. If I can finish it up in its current state (hopefully very soon) and get it merged, then someone else will be able to work with it and blend the functionality with commons-numbers. Someone else? Here are some notes on your questions from before: * Should "QuaternionRotation" inherit from "Quaternion"? That would work conceptually. The quaternions in the QuaternionRotation class are standard quaternions that meet two other criteria: 1) they are unit length, and 2) their scalar component is greater than or equal to zero (in order to standardize the angles involved). It seems indeed the perfect case for inheritance. The one sticking point here is that I'm not sure how this fits with the VALJO concept. If we can get this sorted, then this very well may be the best option. What do you see as a potential issue? * Should "Quaternion" be defined in [Geometry] (and removed from [Numbers])? Perhaps. I've certainly only used them to represent 3D rotations. Are there any other use cases from commons-numbers? Not within [Numbers], but that's the point of those very low-level components/modules: they are common utilities used by higher-level components/libraries/applications. Given that "QuaternionRotation" is a special case of "Quaternion", it is logical to keep the latter at a lower-level, namely in [Numebers], and make [Geometry] depend on it. * Are some utilities defined in "QuaternionRotation" general such that they could be part of the [Numbers] "Quaternion" API. An example might be the transformation between quaternion and matrix (represented as a double[3][3])? The conversion to rotation matrix and slerp are the best candidates here. The other methods rely on core classes from commons-geometry, namely Vector3D. Is "slerp" applicable to a general "Quaternion", or does it assume the additional requirements of "QuaternionRotation"? [Same question applies to all utilities in order to decide where to define them.] One more note: I decided to make a separate package for 3D rotations in my working branch for GEOMETRY-14, so QuaternionRotation is now at https://github.com/darkma773r/commons-geometry/blob/transforms/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/rotation/QuaternionRotation.java. Could you please update it so that it inherits from "Quaternion"? Thanks, Gilles -Matt From: Gilles Sent: Sunday, December 2, 2018 3:57 PM To: dev@commons.apache.org Subject: Re: [Numbers][Geometry] Where to define "quaternion" (Was: Making Quaternion a VALJO) On Sun, 2 Dec 2018 19:20:03 +, Matt Juntunen wrote: Unless anyone objects, I'm going to continue with what I'm working on I certainly don't object on your working to improve the geometry code, but wherever that work overlaps with code being worked on elsewhere (in this case, the "Quaternion" class), then we'd rather have a discussion happening here first. with QuaternionRotation and create a merge request. That way, we'll at least have a reference implementation and baseline functionality for commons-geometry that we can modify later based on what's decided here. My questions below are a start; I'm waiting for answers. Code duplication is bad (TM). Regards, Gilles -Matt From: Gilles Sent: Saturday, December 1, 2018 9:40 PM To: dev@commons.apache.org Subject: Re: [Numbers][Geometry] Where to define "quaternion" (Was: Making Quaternion a VALJO) On Sat, 01 Dec 2018 12:56:34 +0100, Gilles wrote: Hello. On Sat, 1 Dec 2018 06:05:31 +, Matt Juntunen wrote: Hi guys, FYI, I've been working on a quaternion-related class named QuaternionRotation for commons-geometry (see link below). It includes slerp as well as several other geometry-oriented methods, such as conversion to/from axis-angle representations and creation from basis rotations. It's not quite ready for a merge ye
Re: [RNG] How to enable japicmp?
On Sun, 9 Dec 2018 11:15:15 +, sebb wrote:
On Sat, 8 Dec 2018 at 22:47, Gilles
wrote:
Hi.
> [...]
>> from [Lang].[1]
>> The plugin crashes with NPE.
>> [...]
>>
>> Are there problems with "japicmp" that are specific to
multi-modules
>> projects?
>
> It seems that's already fixed:
> https://github.com/siom79/japicmp/issues/210
Thanks for the info.
>
> Worth trying with a newer version.
Looking at the "commons-parent" project, the upgrade was done (to
0.13)
in version 48-SNAPSHOT, which has not been released yet.
One can easily override the plugin versions for testing:
mvn ... --Dcommons.japicmp.version=0.13.0
Tried it: plugin does not crash anymore. :-)
But report is empty. :-{
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Fwd: Re: [Vote] RC2 for releasing Commons RNG v1.2
[Forwarding to ML.] Original Message Subject: Re: [Vote] RC2 for releasing Commons RNG v1.2 Date: Mon, 10 Dec 2018 13:12:33 +0100 From: Gilles To: Alex Herbert On Mon, 10 Dec 2018 10:54:28 +, Alex Herbert wrote: On 06/12/2018 17:15, Gilles wrote: Maven artifacts' SHA-512 hashes in Nexus: commons-rng-1.2-bin-tar.gz=681530e0f26f1ac84b626de4adfc7a5c615b2784157da412b329c5ff33361a7b commons-rng-1.2-bin-tar.gz.asc=5785291f481029c00600cca402ca37fbf9bea64a1b58db4f58c3c41270200e58 commons-rng-1.2-src-tar.gz=89d1d4fb95651c0d008d941b928e468822769a142f69c1e7f174994e3c13285c commons-rng-1.2-bin-zip=09608ac82e654287d69cca991d516cd95f09189f412bf2be1292f10f9b7d103e commons-rng-1.2-src-zip=aabe2a548c991ef89a7f86a5ed6b7ba9847678a0fd87b48d7d40775ba545063d commons-rng-1.2-src-zip.asc=d676fa86a0fa81db7c9c63fb1c86dc5ae23755081186adf6f3650bee3e341e96 commons-rng-1.2-pom.asc=24d621f1b1724134d4d493e0672e9c9a0627c0e8b5614c3ef4d8030ecc14f541 commons-rng-1.2-bin-zip.asc=243e1b663c639116840301d3610abec9b5d6b68f494eee10b164fc7057b4a7e5 commons-rng-1.2-src-tar.gz.asc=7480a80014b3ec58cf3a98c84bb693ba5ea86b02361889c43893752cd9203f33 Sorry I am late with this one. Late but not last I hope... :-} I find these to be SHA-256 hashes. Yes; sorry for the copy/paste mistake. Downloaded all the Nexus artifacts. All .asc signatures verify OK using gpg. User manual: User Manual > Performance I note that the Gaussian samplers table has been updated. I presume it is to remove the JDK 10 times and replace with the documented OpenJDK 1.8. This is good. User Manual > Quality There is a missing link under Dieharder for WELL_44497_B. The number of failed tests is missing in the rng.apt source file so the link to the test result is not visible. Now fixed in "master". 'mvn test site site:stage' using Maven home: /usr/local/apache-maven-3.5.4 Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk-amd64/jre Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-140-generic", arch: "amd64", family: "unix" All builds OK. Local site has the same error in the user manual. +0.5 (just the issue with the table in the user manual) That's a tough mark for just one typo! ;-) Thanks for the review, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Vote] RC2 for releasing Commons RNG v1.2
Ping? On Thu, 06 Dec 2018 18:15:24 +0100, Gilles wrote: Hello. I'd like to release version 1.2 of "Commons RNG". Apache Commons RNG v1.2 (RC2) is available for review: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC2 (svn revision 31410) Git tag is named "RNG_1_2_RC2": https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=tag;h=refs/tags/RNG_1_2_RC2 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1399/org/apache/commons/ Maven artifacts' SHA-512 hashes in Nexus: commons-rng-1.2-bin-tar.gz=681530e0f26f1ac84b626de4adfc7a5c615b2784157da412b329c5ff33361a7b commons-rng-1.2-bin-tar.gz.asc=5785291f481029c00600cca402ca37fbf9bea64a1b58db4f58c3c41270200e58 commons-rng-1.2-src-tar.gz=89d1d4fb95651c0d008d941b928e468822769a142f69c1e7f174994e3c13285c commons-rng-1.2-bin-zip=09608ac82e654287d69cca991d516cd95f09189f412bf2be1292f10f9b7d103e commons-rng-1.2-src-zip=aabe2a548c991ef89a7f86a5ed6b7ba9847678a0fd87b48d7d40775ba545063d commons-rng-1.2-src-zip.asc=d676fa86a0fa81db7c9c63fb1c86dc5ae23755081186adf6f3650bee3e341e96 commons-rng-1.2-pom.asc=24d621f1b1724134d4d493e0672e9c9a0627c0e8b5614c3ef4d8030ecc14f541 commons-rng-1.2-bin-zip.asc=243e1b663c639116840301d3610abec9b5d6b68f494eee10b164fc7057b4a7e5 commons-rng-1.2-src-tar.gz.asc=7480a80014b3ec58cf3a98c84bb693ba5ea86b02361889c43893752cd9203f33 Details of changes since 1.1 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC2/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC2/site/changes-report.html Site: http://commons.apache.org/proper/commons-rng/ KEYS: id=B39617E095CD748DFE505816703413011E22D5B8 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... Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Vote][RESULT] RC2 for releasing Commons RNG v1.2
Hi. RC2 was reviewed by the following people: * Rob Tompkins (+1) * Alex Herbert (+0.5) * Gary Gregory (+1) With my +1, the vote passes with the bare minimum of binding votes. Regards, Gilles On Thu, 06 Dec 2018 18:15:24 +0100, Gilles wrote: Hello. I'd like to release version 1.2 of "Commons RNG". Apache Commons RNG v1.2 (RC2) is available for review: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC2 (svn revision 31410) Git tag is named "RNG_1_2_RC2": https://git-wip-us.apache.org/repos/asf?p=commons-rng.git;a=tag;h=refs/tags/RNG_1_2_RC2 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1399/org/apache/commons/ Maven artifacts' SHA-512 hashes in Nexus: commons-rng-1.2-bin-tar.gz=681530e0f26f1ac84b626de4adfc7a5c615b2784157da412b329c5ff33361a7b commons-rng-1.2-bin-tar.gz.asc=5785291f481029c00600cca402ca37fbf9bea64a1b58db4f58c3c41270200e58 commons-rng-1.2-src-tar.gz=89d1d4fb95651c0d008d941b928e468822769a142f69c1e7f174994e3c13285c commons-rng-1.2-bin-zip=09608ac82e654287d69cca991d516cd95f09189f412bf2be1292f10f9b7d103e commons-rng-1.2-src-zip=aabe2a548c991ef89a7f86a5ed6b7ba9847678a0fd87b48d7d40775ba545063d commons-rng-1.2-src-zip.asc=d676fa86a0fa81db7c9c63fb1c86dc5ae23755081186adf6f3650bee3e341e96 commons-rng-1.2-pom.asc=24d621f1b1724134d4d493e0672e9c9a0627c0e8b5614c3ef4d8030ecc14f541 commons-rng-1.2-bin-zip.asc=243e1b663c639116840301d3610abec9b5d6b68f494eee10b164fc7057b4a7e5 commons-rng-1.2-src-tar.gz.asc=7480a80014b3ec58cf3a98c84bb693ba5ea86b02361889c43893752cd9203f33 Details of changes since 1.1 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC2/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/rng/1.2-RC2/site/changes-report.html Site: http://commons.apache.org/proper/commons-rng/ KEYS: id=B39617E095CD748DFE505816703413011E22D5B8 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... Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Apache Commons RNG version 1.2 release
We are pleased to announce the availability of version 1.2 of the "Apache Commons RNG" library. Apache Commons RNG provides Java implementations of pseudo-random numbers generators. The release notes can be reviewed at https://www.apache.org/dist/commons/rng/RELEASE-NOTES.txt Distribution packages can be downloaded from https://commons.apache.org/proper/commons-rng/download_rng.cgi When downloading, please verify signatures using the KEYS file available at https://www.apache.org/dist/commons/KEYS Maven artifacts are also available in the central Maven repository: https://repo1.maven.org/maven2/org/apache/commons/ Best regards, Gilles (on behalf of the Apache Commons Team) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Apache Commons RNG version 1.2 release
On Wed, 12 Dec 2018 08:34:19 -0500, Rob Tompkins wrote: I was under the impression that we were to wait 24 hours between promotion and announcement as to wait for the mirrors of the world to catch up with the release promotion on the Apache servers. The artefacts are already on Maven Central. Given the stats for past releases, I doubt that the "world" is going to hammer the Apache servers for immediate availability of the release tarball. ;-) Gilles -Rob On Dec 12, 2018, at 8:30 AM, Gilles wrote: We are pleased to announce the availability of version 1.2 of the "Apache Commons RNG" library. Apache Commons RNG provides Java implementations of pseudo-random numbers generators. The release notes can be reviewed at https://www.apache.org/dist/commons/rng/RELEASE-NOTES.txt Distribution packages can be downloaded from https://commons.apache.org/proper/commons-rng/download_rng.cgi When downloading, please verify signatures using the KEYS file available at https://www.apache.org/dist/commons/KEYS Maven artifacts are also available in the central Maven repository: https://repo1.maven.org/maven2/org/apache/commons/ Best regards, Gilles (on behalf of the Apache Commons Team) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Inheritance and ValJO ?
Hi. On Wed, 12 Dec 2018 22:48:54 +, Stephen Colebourne wrote: I think this has already been worked out, but the main reason for no inheritance is that is probably blocks future conversion to value types. Composition instead of inheritance is usually the right solution. Thanks for the reply. Do you think that the implementation here: https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=commons-numbers-quaternion/src/main/java/org/apache/commons/numbers/quaternion/Quaternion.java still counts as ValJO, despite allowing (mandating even) inheritance by inner classes (as per your paragraph that ends with "The need for this is rare however.") What I don't quite see is the consequences of the class not being final... Gilles Stephen On Sun, 9 Dec 2018 at 10:21, Gilles wrote: Hello. After the discussion quote below, the conclusion was to go with inheritance: https://issues.apache.org/jira/browse/NUMBERS-80 However, it would make "Quaternion" fail the "ValJO" definition[1] that mandates that all constructors be private. Would a protected constructor really be an issue? [In the case of "Quaternion", the subclass constructor would only perform additional validation (cf. below for details).] Thanks, Gilles [1] https://blog.joda.org/2014/03/valjos-value-java-objects.html On Mon, 03 Dec 2018 10:31:42 +0100, Gilles wrote: > Hi. > > On Mon, 3 Dec 2018 03:56:02 +, Matt Juntunen wrote: >> I was just thinking from a practical standpoint. My current >> QuaternionRotation class is still in my working branch for >> GEOMETRY-14 >> and so isn't really accessible to anyone. If I can finish it up in >> its >> current state (hopefully very soon) and get it merged, then someone >> else will be able to work with it and blend the functionality with >> commons-numbers. > > Someone else? > >> >> Here are some notes on your questions from before: >> >> * Should "QuaternionRotation" inherit from "Quaternion"? >> >> That would work conceptually. The quaternions in the >> QuaternionRotation class are standard quaternions that meet two >> other >> criteria: 1) they are unit length, and 2) their scalar component is >> greater than or equal to zero (in order to standardize the angles >> involved). > > It seems indeed the perfect case for inheritance. > >> The one sticking point here is that I'm not sure how this >> fits with the VALJO concept. If we can get this sorted, then this >> very >> well may be the best option. > > What do you see as a potential issue? > >> >> * Should "Quaternion" be defined in [Geometry] (and removed from >> [Numbers])? >> >> Perhaps. I've certainly only used them to represent 3D rotations. >> Are >> there any other use cases from commons-numbers? > > Not within [Numbers], but that's the point of those very low-level > components/modules: they are common utilities used by higher-level > components/libraries/applications. > > Given that "QuaternionRotation" is a special case of "Quaternion", > it is logical to keep the latter at a lower-level, namely in > [Numebers], and make [Geometry] depend on it. > >> >> * Are some utilities defined in "QuaternionRotation" general >> such that they could be part of the [Numbers] "Quaternion" API. >> An example might be the transformation between quaternion and >> matrix (represented as a double[3][3])? >> >> The conversion to rotation matrix and slerp are the best candidates >> here. The other methods rely on core classes from commons-geometry, >> namely Vector3D. > > Is "slerp" applicable to a general "Quaternion", or does it assume > the additional requirements of "QuaternionRotation"? > [Same question applies to all utilities in order to decide where to > define them.] > >> >> One more note: I decided to make a separate package for 3D rotations >> in my working branch for GEOMETRY-14, so QuaternionRotation is now >> at >> >> https://github.com/darkma773r/commons-geometry/blob/transforms/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/rotation/QuaternionRotation.java . > > Could you please update it so that it inherits from "Quaternion"? > > Thanks, > Gilles > >> >> -Matt >> >> From: Gilles >> Sent: Sunday, December 2, 2018 3:57 PM >> To: dev@commons.apache.org >> Subject: Re: [Numbers][Geometry] Where to define "quaternion&q
[Release-plugin] Auto-generated download page is wrong (Was: Returned post for annou...@apache.org)
Hi. [See below, the rejected announce mail for Commons RNG v1.2.] Release candidates were generated with the "release-plugin".[1] The "xml" template files were generated using $ mvn -Prelease commons-build:download-page Please advise on the appropriate incantations (that would lead to the download page being generated with correct links to the checksum files (SHA-256). Thanks, Gilles [1] http://commons.apache.org/proper/commons-release-plugin/index.html On 13 Dec 2018 09:16:38 -, announce-ow...@apache.org wrote: Hi! This is the ezmlm program. I'm managing the annou...@apache.org mailing list. I'm sorry, your message (enclosed) was not accepted by the moderator. If the moderator has made any comments, they are shown below. >>>>> Sorry, but the download page is not acceptable at present. SHA1 is now deprecated; please replace with SHA256/SHA512, and resend the announce message when this has been done. Thanks Sebb <<<<< <<<<< - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [numbers] propose making BigFraction an extension of Fraction
Hi Eric.
On Thu, 13 Dec 2018 11:20:12 -0800, Eric Barnhill wrote:
Right now BigFraction and Fraction are separate parallel classes.
I propose altering this so that BigFraction extends Fraction,
overrides its
methods, but also keeps its own unique methods.
I think it would be an improvement to the API to have both classes
share
the same interface (and indeed an interface-based solution would be
possible, but strikes me as overkill, since I don't see any
additional
classes beyond Fraction and BigFraction). BigFraction would in
addition
have its current methods to convert BigIntegers to ints and longs.
Among the elegancies afforded by this change, if a Fraction operation
causes overflow as previously discussed, a BigFraction could be
returned
and should be able to handle all further calls to Fraction unaltered.
(This
might not always be desired behavior, so Fraction may need to contain
a
setting to either throw and exception, or convert to BigFraction in
case of
overflow.)
Doesn't this setting achieve at runtime what the application
developer should decide at compile time (by instantiating the
class that has the desired behaviour)?
So I propose writing a ticket for this change. As sub-points on the
ticket
the BigFraction class could be conformed to Fraction class in terms
of
reduction of constants and producing a VALJO.
Inheritance and ValJO turn out being contradictory (see thread
with subject "Inheritance and ValJO ?").
And (IIUC) the workaround/alternative hinted at by Stephen
in that same thread might not be directly applicable because,
here, the instance fields are different in "Fraction" and
"BigFraction" ("long" vs "BigInteger").
I've just noticed that "BigInteger" is not final; hence
"BigFraction" cannot be a ValJO either.[1]
I don't think that we should rule out a "Fraction" interface.
A "Fraction64" class would be an explicit "long"-based ValJO
(with operations that are fast, but throw in case of overflow).
"BigFraction" would be the fail-safe implementation. If it
allows for faster operation in some cases, it could hold
a "Fraction64" instance field (i.e. what you propose would
be achieved through composition rather than inheritance).
Does this make sense?
Regards,
Gilles
[1] So this issue:
https://issues.apache.org/jira/browse/NUMBERS-75
should probably be resolved as "Invalid".
Eric
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [numbers/general] unlikely argument type warning
On Thu, 13 Dec 2018 11:39:05 -0800, Eric Barnhill wrote:
For the line:
Assert.assertFalse(zero.equals(Double.valueOf(0)));
What is it testing?
Conceptually, I'd expect "assertTrue" (zero as a fraction
is equal to zero as a double).
Eclipse is producing a warning:
"Unlikely argument type for equals(): Double seems to be unrelated to
Fraction"
Does anyone have a suggestion for how to handle this warning, thank
you.
Perhaps Eclipse indicates that the test is useless (since
"Double" is not a subclass of "Fraction").
And perhaps "Fraction" should overload "equals":
public boolean equals(double x, int ulp) {
return Precision.equals(doubleValue(), x, ulp);
}
public boolean equals(Number x, int ulp) {
return equals(x.doubleValue, ulp);
}
public boolean equals(double x) {
return equals(doubleValue(), x, 1);
}
Gilles
Eric
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [geometry] 1.0 Roadmap
Hi. On Fri, 7 Sep 2018 02:29:21 +, Matt Juntunen wrote: Hi all, I've been working on the new commons-geometry component for a while now and I wanted to share with everyone the current state of the project and what I'm picturing for the future, up to a 1.0 release. Here is where we are now: 1. All of the original geometry code from commons-math has been moved to commons-geometry. 2. Code has been split into a number of distinct modules, per Java 9+ conventions. 3. The old Vector classes have been completely redesigned and refactored into separate Point and Vector classes to better reflect the underlying math. 4. All Point and Vector classes are now VALJOs. 5. Support for spherical and polar coordinates has been added. Here is what I'd like to still accomplish before a 1.0 release (in order of priority): 1. Add additional Vector methods (GEOMETRY-9) -- This includes methods like lerp, project, and reject among others. A pull request has been submitted for this and is in discussion. Done. 2. Vector normalization optimizations (GEOMETRY-10) -- We can avoid a lot of computation by making some tweaks here. I've started on this but do not yet have a pull request. Done. 3. Add matrix-based AffineTransform?D classes (GEOMETRY-14) -- We are sorely lacking an API to translate, rotate, and scale. In progress. PR provided but design is under discussion: https://issues.apache.org/jira/browse/GEOMETRY-14 4. Encapsulate concept of tolerance (GEOMETRY-11) -- We currently use raw double tolerance values to help determine equality between floating point numbers. I think we should encapsulate this into a GeometryContext class to ensure that this is done consistently and to allow us to easily tweak the algorithm if needed. If anyone has any ideas for how to best maintain floating point accuracy here, that would be great. Open. 5. API cleanup for Region, Hyperplane, and BSPTree (no JIRA issue yet) -- This is a big one and kind of ill-defined. One of the main gripes I and other people at my work have had with the old commons-math geometry code was that it was awkward to use. You had to jump through a bunch of hoops to do things like get the vertices of the union of two 2D shapes. I'd like to try to clean this up and streamline some of the common use cases. Comments and feedback on this would be great. Status? 6. BSPTree optimizations (no JIRA issue yet) -- I have some ideas I'd like to try out to speed up the BSP tree code. My unofficial benchmark is to convert a model of the Utah teapot I have with ~1000 facets into a PolygonsSet and back. The current code cannot do this. It takes forever and then fails, I believe due to accumulated floating point errors. If we can get the code to be able to do this correctly and in a reasonable amount of time, then I'd feel good about making a release. Status? Thoughts? Comments? I have a project at work coming up near the end of the year that I'd really love to use commons-geometry on, so that's what I'm aiming for in terms of a timeline. I'm very much for RERO. However, given the lack of feedback for this component, we cannot be confident that no corners have been cut for such a large code base (8526 LOC as of today[1]). Hence I'd like to release (ASAP) a _beta_ version of what we have, such that the functionality can be put to use (and problems, design or bugs, arise from actual use cases). [Geometry] depends on [Numbers] whose first release is also long overdue! But the lack of feedback applies to the latter too, and I thus also propose to prepare a beta version of it. The safer approach[2] is to put _all_ codes under a new top-level package (e.g. "org.apache.commons.geometry.beta"). That name would remain the same for all beta releases, _without_ any BC requirement (hence JAR hell _can_ occur, but is explicitly allowed in beta releases[3]). WDYT? If we agree, what timeline are we talking about? Regards, Gilles Thanks, Matt Juntunen [1] Down 10% from the original "Commons Math" code base, but with more features (IIUC). :-) Actually, AFAICT, the work by Matt is the first ever large scale review/refactoring of the code contained in "geometry" package of "Commons Math". [2] IIUC the scarce discussions, without any firm conclusions, about how our "Commons" project should deliver alpha/beta releases. [Directions still welcome...] [3] Cf. ML archive. If PMC members disagree, please speak up now. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CSV] Records as Lists
On Thu, 13 Dec 2018 11:33:45 -0700, Gary Gregory wrote: Hi All, I am looking for opinions on turning a CSV record into a list, as opposed to the minimal current implementation. There would be side-effects like a record becoming writable instead of read-only as the current implementation. IIUC, the patch referred to below does not add those side-effects. Memory footprint would also be a concern. The patch does not change that either. Gilles Please see https://github.com/apache/commons-csv/pull/35 Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Numbers] 1.0 Roadmap
Hi. I've proposed to release a beta version of "Commons Numbers"[1]. Any blockers? Regards, Gilles [1] https://markmail.org/message/3wskoxpc2l7itiao - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Release-plugin] Auto-generated download page is wrong (Was: Returned post for annou...@apache.org)
Ping? Is this a "release-plugin" bug to report on JIRA (COMMONSSITE), or a usage issue? I did not spot a recent documentation resource that warns of this (new?) problem. Gilles On Thu, 13 Dec 2018 16:38:38 +0100, Gilles wrote: Hi. [See below, the rejected announce mail for Commons RNG v1.2.] Release candidates were generated with the "release-plugin".[1] The "xml" template files were generated using $ mvn -Prelease commons-build:download-page Please advise on the appropriate incantations (that would lead to the download page being generated with correct links to the checksum files (SHA-256). Thanks, Gilles [1] http://commons.apache.org/proper/commons-release-plugin/index.html On 13 Dec 2018 09:16:38 -, announce-ow...@apache.org wrote: Hi! This is the ezmlm program. I'm managing the annou...@apache.org mailing list. I'm sorry, your message (enclosed) was not accepted by the moderator. If the moderator has made any comments, they are shown below. >>>>> Sorry, but the download page is not acceptable at present. SHA1 is now deprecated; please replace with SHA256/SHA512, and resend the announce message when this has been done. Thanks Sebb <<<<< <<<<< - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [exec] Add stream api to improve exec ease of use
Hello.
On Sun, 9 Dec 2018 13:14:15 +0800, ideal wrote:
Hi all, the current use of java8 has been very extensive. I designed
a
stream api based simplified `exec` and verified its usability in a
lot of
scenarios. Share my api now.
demo:
JVMLauncher launcher =
JVMLaunchers.newJvm()
.setCallable(() -> {
System.out.println(" exec task jvm
start ***");
TimeUnit.SECONDS.sleep(1);
System.out.println(" exec task jvm
stop ***");
return 1;
})
.setXms("16m")
.setXmx("16m")
.addUserjars(Collections.emptyList())
.setConsole((msg) -> System.err.println(msg))
.build();
VmFuture out = launcher.startAndGet(); --run
It seems that the [exec] component has become unmaintained: last
release happened more than 4 years ago.
In order to make it worth reviving it (if there people willing
to do it), it would be useful to list what your project provides
that is missing from recent Java versions (e.g. enhancements to
the "Process"-related JDK classes).
Thanks,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CSV] Records as Lists
Hi. On Tue, 18 Dec 2018 07:22:00 + (UTC), Bruno P. Kinoshita wrote: From what I understood from the previous messages & discussion on GitHub, it would be more convenient for users to be able to have a List instead of an Iterable, Why "instead"? The patch makes the class a subclass of "List"; and "List" implements "Iterable". or instead of having to call the #toList() or convert to a List in some other way. I commented in the pull request, that I don't think there would be a performance penalty in doing so (at least I don't think so, as the values are not streamed, but rather kept in the private values array). However, I think we are delivering an Iterable that's fully capable to be used as an Iterable now. Whereas the proposal would make it a read-only list, as that returned from unmodifiableList, That's not what the patch does: https://docs.oracle.com/javase/7/docs/api/java/util/AbstractList.html i.e. throwing exceptions for add/clear/etc operations. The original code (using "Arrays.asList") could not do those operations: https://docs.oracle.com/javase/7/docs/api/java/util/Arrays.html#asList(T...) In my opinion, I prefer to keep it as an Iterable, leave the toList method, as I think current users could be affected How? [In the original code, "toList" is private.] by accidentally trying to reuse CSVRecord while reading from one input and writing to an output stream. I don't understand this. Regards, Gilles So I'm -0 for it. Bruno From: sebb To: Commons Developers List Sent: Tuesday, 18 December 2018 12:24 AM Subject: Re: [CSV] Records as Lists What is the use-case for using lists? On Thu, 13 Dec 2018 at 18:34, Gary Gregory wrote: Hi All, I am looking for opinions on turning a CSV record into a list, as opposed to the minimal current implementation. There would be side-effects like a record becoming writable instead of read-only as the current implementation. Memory footprint would also be a concern. Please see https://github.com/apache/commons-csv/pull/35 Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Help with migrating one of OpenJPA classes to commons-collections4
On Tue, 18 Dec 2018 22:03:04 +0700, Maxim Solodovnik wrote:
It seems I'm unable to commit to SVN:
URL: https://dist.apache.org/repos/dist/release/commons
SendingKEYS
Transmitting file data .svn: E195023: Commit failed (details follow):
svn: E195023: Changing file
'/home/solomax/work/apache-dist/release/commons/KEYS' is forbidden by
the
server
svn: E175013: Access to
'/repos/dist/!svn/txr/31592-qod/release/commons/KEYS' forbidden
Can someone help me with access rights?
Not me.
But I've added your key (revision 31593).
Hope it gets you a little further,
Gilles
On Tue, 18 Dec 2018 at 21:22, Maxim Solodovnik
wrote:
Moving conversation to dev@ list
I was able to create branch using gitbox remote
Will proceed,
Thanks for the tip
On Tue, 18 Dec 2018 at 21:14, Gilles
wrote:
Hi.
On Tue, 18 Dec 2018 20:54:22 +0700, Maxim Solodovnik wrote:
> Hello Gilles,
>
> I read documentation and as far as I can see To perform release I
> need
> rights to create branch
>
> git remote -v
> origin g...@github.com:apache/commons-collections.git (fetch)
> origin g...@github.com:apache/commons-collections.git (push)
>
> git push -u origin 4.3-release
> ERROR: Permission to apache/commons-collections.git denied to
> solomax.
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
The repository (at Apache) is here:
https://gitbox.apache.org/repos/asf?p=commons-collections.git
We were told that it should now be possible to also write
through GitHub, but I don't know if and how it should work.
IMO, the easiest would be to clone the above, and try again
with that. [If it still does not work, then perhaps the issue
is that the "all-Apache-committers-are-committers" resolution
was not applied.]
Gilles
P.S. We should move this conversation over to the "dev" ML.
>
> Shall I use SVN? Or some other remote?
>
>
>
> On Tue, 18 Dec 2018 at 16:04, Maxim Solodovnik
> wrote:
>
>> Thanks Gilles,
>>
>> will try to create RC tonight
>>
>> On Tue, 18 Dec 2018 at 15:55, Gilles
>> wrote:
>>
>>> Hi.
>>>
>>> On Tue, 18 Dec 2018 09:52:15 +0700, Maxim Solodovnik wrote:
>>> > I can create RC, no problem
>>> > But
>>> > 1) I need my signing key [1] to be added to official KEYS
>>>
>>> The file is here:
>>>https://dist.apache.org/repos/dist/release/commons/KEYS
>>>
>>> > 2) Do you have description of your release process? I was
unable
>>> to
>>> > find one
>>>
>>>
http://commons.apache.org/proper/commons-release-plugin/index.html
>>>
>>> Also, a step-by-step recipe is here:
>>>
>>>
>>>
>>>
https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=blob;f=doc/release/release.howto.txt
>>>
>>> [It is for a multimodule maven project ("Commons RNG"); it
>>> mentions problems with the release process that might need
>>> manual adjustments.]
>>>
>>> If you encounter something that does not work as noted,
>>> please report it here, and on the bug tracking system:
>>>https://issues.apache.org/jira/projects/COMMONSSITE
>>>
>>> > 3) most probably I will need some rights
>>>
>>> The "Commons" project has granted "write" access to all
>>> Apache committers.
>>> [But some repositories perhaps miss the actual settings
>>> to make it work. You'll have to try...]
>>>
>>> HTH,
>>> Gilles
>>>
>>> > [1]
https://github.com/apache/openmeetings/blob/master/KEYS#L88
>>> >
>>> > On Tue, 18 Dec 2018 at 01:06, sebb wrote:
>>> >
>>> >> On Mon, 17 Dec 2018 at 15:38, Gary Gregory
>>>
>>> >> wrote:
>>> >> >
>>> >> > I am on the road driving this week, my availability is
>>> limited.
>>> >> >
>>> >> > WRT being a RM, I think you need PMC karma for that. Sebb
>>> might be
>>> >> able
>>> >> to
>>> >> > confirm.
>>> >>
>>> >> Creating the dist/dev release candidate only requires
project
>>> >> committer karma; Commons requires the same for dist/release
>>> >>
>>> >> I don't know about Nexus; I imagine at least LDAP commons
>>> committer
>>> >> membership is required.
>>> >>
>>> >> There's no harm in try
Re: Help with migrating one of OpenJPA classes to commons-collections4
Hello. On Tue, 18 Dec 2018 23:05:12 +0700, Maxim Solodovnik wrote: Thanks a lot Unfortunately the next error is: Failed to deploy artifacts: Could not transfer artifact org.apache.commons:commons-collections4:jar:4.3 from/to apache.releases.https ( https://repository.apache.org/service/local/staging/deploy/maven2): Access denied to: https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar I'm release manger for Apache OpenMeetings and just double-check I can access Staging Repos at repository.apache.org , so I guess there are additional restrictions here would appreciate any help/hint :) I don't know how to change the permissions (I don't think I have the privilege anyway), and the PMC chair is AFK for a couple more days IIUC. :-( Perhaps someone with a taller hat. :-} Sorry for the inconvenience; it looks like you are first one to try and exercise those privileges voted several years ago... Gilles On Tue, 18 Dec 2018 at 22:54, Gilles wrote: On Tue, 18 Dec 2018 22:03:04 +0700, Maxim Solodovnik wrote: > It seems I'm unable to commit to SVN: > > URL: https://dist.apache.org/repos/dist/release/commons > > SendingKEYS > Transmitting file data .svn: E195023: Commit failed (details follow): > svn: E195023: Changing file > '/home/solomax/work/apache-dist/release/commons/KEYS' is forbidden by > the > server > svn: E175013: Access to > '/repos/dist/!svn/txr/31592-qod/release/commons/KEYS' forbidden > > Can someone help me with access rights? Not me. But I've added your key (revision 31593). Hope it gets you a little further, Gilles > > On Tue, 18 Dec 2018 at 21:22, Maxim Solodovnik > wrote: > >> Moving conversation to dev@ list >> >> I was able to create branch using gitbox remote >> Will proceed, >> >> Thanks for the tip >> >> >> On Tue, 18 Dec 2018 at 21:14, Gilles >> wrote: >> >>> Hi. >>> >>> On Tue, 18 Dec 2018 20:54:22 +0700, Maxim Solodovnik wrote: >>> > Hello Gilles, >>> > >>> > I read documentation and as far as I can see To perform release I >>> > need >>> > rights to create branch >>> > >>> > git remote -v >>> > origin g...@github.com:apache/commons-collections.git (fetch) >>> > origin g...@github.com:apache/commons-collections.git (push) >>> > >>> > git push -u origin 4.3-release >>> > ERROR: Permission to apache/commons-collections.git denied to >>> > solomax. >>> > fatal: Could not read from remote repository. >>> > >>> > Please make sure you have the correct access rights >>> > and the repository exists. >>> >>> The repository (at Apache) is here: >>>https://gitbox.apache.org/repos/asf?p=commons-collections.git >>> >>> We were told that it should now be possible to also write >>> through GitHub, but I don't know if and how it should work. >>> >>> IMO, the easiest would be to clone the above, and try again >>> with that. [If it still does not work, then perhaps the issue >>> is that the "all-Apache-committers-are-committers" resolution >>> was not applied.] >>> >>> Gilles >>> >>> P.S. We should move this conversation over to the "dev" ML. >>> >>> > >>> > Shall I use SVN? Or some other remote? >>> > >>> > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CSV] Records as Lists
Hi. On Tue, 18 Dec 2018 21:33:42 + (UTC), Bruno P. Kinoshita wrote: Hi Gilles! Sorry, just came back from a long holiday, speaking Portuguese only. Semantic, vocabulary, etc, in English is a bit laggy right now. On Tue, 18 Dec 2018 07:22:00 + (UTC), Bruno P. Kinoshita wrote: From what I understood from the previous messages & discussion on GitHub, it would be more convenient for users to be able to have a List instead of an Iterable, Why "instead"? The patch makes the class a subclass of "List"; and "List" implements "Iterable". That's right, I meant to say that it would be an AbstractList, and not only an Iterable any more. I think that's the reporter's purpose: get more functionality... However, I think we are delivering an Iterable that's fully capable to be used as an Iterable now. Whereas the proposal would make it a read-only list, as that returned from unmodifiableList, That's not what the patch does: https://docs.oracle.com/javase/7/docs/api/java/util/AbstractList.html I think tis another semantic/communication issue. From the link above: "Note that this implementation throws an UnsupportedOperationException unless remove(int index) or removeRange(int fromIndex, int toIndex) is overridden." That's what I meant. By extending AbstractList, users could now call remove and other methods, that would result in the exception above (similarly to the list returned via Collections.unmodifiableList). "remove()" can also be called on the instance return by the "iterator()" method; and it will throw just the same. How? [In the original code, "toList" is private.] Oh, good point!!! I wrote the e-mail from memory, a few days after reading the code, and after just arriving at home. Mea culpa. by accidentally trying to reuse CSVRecord while reading from one input and writing to an output stream. I don't understand this. That was a contrived example. Say you read the records, transform the Iterable into a List, and add/remove/clear columns/rows while processing the CSVRecord (e.g. you could be using commons-text and other libs to filter/process the entries). Then you get these values and create a new CSV. IIUC, the current code cannot do that because it uses "Arrays.asList" to return a _view_ of the underlying array (fixed length, remove not supported). When users realize they now have a List instead, they could rely on the CSVRecord object, instead of creating new Lists, and get some runtime errors. Corner case, and - again - a contrived example. Still not sure I get it; the behaviour does not seem to change apart from providing more functionality. But I'm not opposing the change, just don't see the need for using AbstractList (though I've been writing Python for the past couple of months, so my Java-fu isn't really sharp right now). The reporter mentioned "subList". Regards, Gilles Cheers Bruno From: Gilles To: dev@commons.apache.org Sent: Wednesday, 19 December 2018 1:28 AM Subject: Re: [CSV] Records as Lists Hi. On Tue, 18 Dec 2018 07:22:00 + (UTC), Bruno P. Kinoshita wrote: From what I understood from the previous messages & discussion on GitHub, it would be more convenient for users to be able to have a List instead of an Iterable, Why "instead"? The patch makes the class a subclass of "List"; and "List" implements "Iterable". or instead of having to call the #toList() or convert to a List in some other way. I commented in the pull request, that I don't think there would be a performance penalty in doing so (at least I don't think so, as the values are not streamed, but rather kept in the private values array). However, I think we are delivering an Iterable that's fully capable to be used as an Iterable now. Whereas the proposal would make it a read-only list, as that returned from unmodifiableList, That's not what the patch does: https://docs.oracle.com/javase/7/docs/api/java/util/AbstractList.html i.e. throwing exceptions for add/clear/etc operations. The original code (using "Arrays.asList") could not do those operations: https://docs.oracle.com/javase/7/docs/api/java/util/Arrays.html#asList(T...) In my opinion, I prefer to keep it as an Iterable, leave the toList method, as I think current users could be affected How? [In the original code, "toList" is private.] by accidentally trying to reuse CSVRecord while reading from one input and writing to an output stream. I don't understand this. Regards, Gilles So I'm -0 for it. Bruno From: sebb To: Commons Developers List Sent: Tuesday, 18 December 2018 12:24 AM Subject: Re: [CSV] Records as Lists What is the use-case for using lists? On Thu, 1
[All][RNG] Fixing the download page (Was: [Release-plugin] Auto-generated download page is wrong (Was: Returned post for annou...@apache.org))
On Mon, 17 Dec 2018 15:28:46 +0100, Gilles wrote: Ping? I found this: https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commitdiff;h=f73546863611e5dd850fd311277f2019259489ce;hp=288c8b5196ab29e0e2ca50182a28f217e0828833 Please confirm whether the fix is "manual". Gilles Is this a "release-plugin" bug to report on JIRA (COMMONSSITE), or a usage issue? I did not spot a recent documentation resource that warns of this (new?) problem. Gilles On Thu, 13 Dec 2018 16:38:38 +0100, Gilles wrote: Hi. [See below, the rejected announce mail for Commons RNG v1.2.] Release candidates were generated with the "release-plugin".[1] The "xml" template files were generated using $ mvn -Prelease commons-build:download-page Please advise on the appropriate incantations (that would lead to the download page being generated with correct links to the checksum files (SHA-256). Thanks, Gilles [1] http://commons.apache.org/proper/commons-release-plugin/index.html On 13 Dec 2018 09:16:38 -, announce-ow...@apache.org wrote: Hi! This is the ezmlm program. I'm managing the annou...@apache.org mailing list. I'm sorry, your message (enclosed) was not accepted by the moderator. If the moderator has made any comments, they are shown below. >>>>> Sorry, but the download page is not acceptable at present. SHA1 is now deprecated; please replace with SHA256/SHA512, and resend the announce message when this has been done. Thanks Sebb <<<<< <<<<< - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Help with migrating one of OpenJPA classes to commons-collections4
On Wed, 19 Dec 2018 06:59:26 +0700, Maxim Solodovnik wrote: I found it here: https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=blob;f=doc/release/release.howto.txt#l300 Shall I drop current staging repo and restart the build without this profile? Yes. As I wrote, [RNG] is a modular project and "commons-rng-examples" is one of its modules. You can safely ignore any "-Pcommons-rng-examples" switch. The rest of the command line is fine. For a non-modular project, you might be lucky to not hit the bugs of the "release-plugin". On Wed, 19 Dec 2018 at 06:57, sebb wrote: On Tue, 18 Dec 2018 at 23:37, Maxim Solodovnik wrote: > > Thanks a lot Sebb, > > staging repo was created successfully. > `mvn -Duser.name="solomax" -Pcommons-collections -Prelease clean site > site:stage deploy` > > but I got following error during the build: > [WARNING] The requested profile "commons-collections" could not be > activated because it does not exist. That's because it does not exist. Why did you add "-Pcommons-collections" to the command-line? Is it documented to do so somewhere? > [ERROR] Failed to execute goal > org.apache.commons:commons-release-plugin:1.3:stage-distributions > (stage-distributions) on project commons-collections4: Failed to add files > to scm -> [Help 1] > > It seems not important to me, would it be OK to ignore it and proceed with > RC1? I don't use the release plugin so I don't know about that. > Another question: during release preparation I have created `4.3-release` > branch, it has zero commits, and I believe should be dropped (and in fact > shouln't be created) > Documentation states: "As branches deletion is now forbidden at > Apache, we will use a specific > release branch for every version" That's the convention followed up to now. But we do delete feature and bugfix branches that were merged into "master", or experimental branches that have become stale. Gilles > > Can I delete this useless branch and propose documentation update? > > On Wed, 19 Dec 2018 at 00:04, sebb wrote: > > > I think the issue with dist/release/commons is that you need to be > > listed as a project committer, i.e. you need to be a Commons > > committer. > > > > Possibly the same applies to Nexus. > > > > I have added you as a Commons committer. > > > > On Tue, 18 Dec 2018 at 16:24, Maxim Solodovnik > > wrote: > > > > > > Thanks a lot for the help :) > > > Glad to check the release process ;) > > > > > > On Tue, 18 Dec 2018 at 23:19, Gilles > > wrote: > > > > > > > Hello. > > > > > > > > On Tue, 18 Dec 2018 23:05:12 +0700, Maxim Solodovnik wrote: > > > > > Thanks a lot > > > > > > > > > > Unfortunately the next error is: Failed to deploy artifacts: Could > > > > > not > > > > > transfer artifact org.apache.commons:commons-collections4:jar:4.3 > > > > > from/to > > > > > apache.releases.https ( > > > > > https://repository.apache.org/service/local/staging/deploy/maven2): > > > > > Access > > > > > denied to: > > > > > > > > > > > > > > > > https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar > > > > > > > > > > I'm release manger for Apache OpenMeetings and just double-check I > > > > > can > > > > > access Staging Repos at repository.apache.org > > > > > , so I guess there are additional restrictions here > > > > > > > > > > would appreciate any help/hint :) > > > > > > > > I don't know how to change the permissions (I don't think I have > > > > the privilege anyway), and the PMC chair is AFK for a couple more > > > > days IIUC. :-( > > > > > > > > Perhaps someone with a taller hat. :-} > > > > > > > > Sorry for the inconvenience; it looks like you are first one to > > > > try and exercise those privileges voted several years ago... > > > > > > > > Gilles > > > > > > > > > > > > > > On Tue, 18 Dec 2018 at 22:54, Gilles < gil...@harfang.homelinux.org> > > > > > wrote: > > > > > > > > > >> On Tue, 18 Dec 2018 22:03:04 +0700, Maxim Solodovnik wrote: > > > > >> > It seems I'm unable
Re: [All][RNG] Fixing the download page
On Wed, 19 Dec 2018 09:48:30 +, sebb wrote: On Wed, 19 Dec 2018 at 00:05, Gilles wrote: On Mon, 17 Dec 2018 15:28:46 +0100, Gilles wrote: > Ping? I found this: https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commitdiff;h=f73546863611e5dd850fd311277f2019259489ce;hp=288c8b5196ab29e0e2ca50182a28f217e0828833 Please confirm whether the fix is "manual". Not sure what you mean by that. I mean that the release plugin does not regenerate the "download.xml" page (whereas this is typically a task that can be automated). AFAIK the fix listed above has yet to be included in the release of commons-build plugin. Someone needs to release 1.10 In the meantime, to use 1.10-SNAPSHOT you can use a command of the form: $ mvn org.apache.commons:commons-build-plugin:1.10-SNAPSHOT:download-page Add -Dcommons.release.version=m.n.o to override the pom version if necessary. Thanks; that's what I missed. Just tried and... two problems: 1. The snapshot does not seem to be available from the usual place (Should it be generated by Jenkins?); I had to build the plugin and "install" it locally. 2. Running the above results in an error: ---CUT--- [ERROR] Failed to execute goal org.apache.commons:commons-build-plugin:1.10-SNAPSHOT:download-page (default-cli) on project commons-rng: Failed to execute: Executing Ant script: generate-xdocs.build.xml [download-page]: Failed to execute.: The following error occurred while executing this line: [ERROR] /tmp/plexus-ant-component10719660622814449892.build.xml:215: Unable to create javax script engine for javascript ---CUT--- [Note: this is on Java 9 and Java 10; on Java 8 it works fine.] Since the commons build plugin is only used to automate editing the download source file it does not matter whether you use a SNAPSHOT or edit the file manually. Whatever gets the job done. Sure. Even "manual" is fine as long as we are not mislead top believe that this is taken of care of automatically. The step-by-step release recipe detailed in the "doc" directory of "Commons RNG" had worked flawlessly for its v1.0 release. But then for the v1.1 release (done by Rob, with the release-plugin) some steps became outdated, with some of their replacement not fully working (as I've detailed in other threads), manual tweaks had to be done, but are nowhere documented; this is understandable since the plugin is in development; but what is less, is that the release process was broken for some components (namely "Commons RNG"), and contrary to what you wrote several times, there was no easy way back (i.e. downgrading CP) because the component's POM relied on CP for common configuration necessary to fix general problems. Gilles > > Is this a "release-plugin" bug to report on JIRA (COMMONSSITE), > or a usage issue? The download plugin is basically a script to automate maintenance of the download.xml source file. AFAIK it has nothing to do with the release plugin. IMO, it has (cf. above); it does not make sense to prepare an RC with a wrong "download" page since it's likely to be a blocker (during the vote, or ... at the announcement). Except of course you need ensure the download xml file is correct before starting the release. I do not agree; For as long as I've been here, the advice (documented) has been: "Run this command [...] to regenerate the download page". If/when the Apache policy changes, it should become a priority task to update we rely on to make releases (that should abide by that policy). We cannot ask that people who use _recommended_ procedures suddenly do without. The release-plugin goes in the right direction, but not all basic expectations are met yet; so that people trying it all get hit by the same problems (cf. current attempt for [Collections]). Regards, Gilles > I did not spot a recent documentation resource that warns of > this (new?) problem. > > Gilles > > On Thu, 13 Dec 2018 16:38:38 +0100, Gilles wrote: >> Hi. >> >> [See below, the rejected announce mail for Commons RNG v1.2.] >> >> Release candidates were generated with the "release-plugin".[1] >> The "xml" template files were generated using >> $ mvn -Prelease commons-build:download-page >> >> Please advise on the appropriate incantations (that would lead >> to the download page being generated with correct links to the >> checksum files (SHA-256). >> >> Thanks, >> Gilles >> >> [1] >> http://commons.apache.org/proper/commons-release-plugin/index.html >> >> On 13 Dec 2018 09:16:38 -, announce-ow...@apache.org wrote: >>> Hi! This is the ezmlm program. I'm managing the >>> annou...@apache.org mailing list. >>> >>> I'm sorry, your mes
Re: [VOTE][RC1] Commons collections 4.3
Hi. Congratulations for getting that far in a fairly short time. ;-) The BC report (Clirr) notes several incompatible changes: https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC1/site/clirr-report.html [No idea whether that was expected. If so, perhaps there should be a remark in the release notes?] In the site, the link to the release note is dead: https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC1/site/release_4_3.html [File must be copied manually (?). It does not seem to be at same place in "Collections" and in "RNG"!] On Wed, 19 Dec 2018 20:41:15 +0700, Maxim Solodovnik wrote: This is a [VOTE] for releasing Apache Commons collections 4.3 Tag name: collections-4.3-RC1 (signature can be checked from git using 'git tag -v') OK. Tag URL: https://gitbox.apache.org/repos/asf?p=commons-collections.git;a=commit;h=5f959fd8e77bf28f6286cfb4d1e1fff27167f803 Commit ID the tag points at: 5f959fd8e77bf28f6286cfb4d1e1fff27167f803 OK. Site: https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC1/site/index.html Download page will be wrong (cf. other thread with subject "Fixing the download page). Distribution files (committed at revision 31605): https://dist.apache.org/repos/dist/dev/commons/collections/ Distribution files hashes (SHA256): 201e1d527c67643b4e75065e113006d0610e8bf5620b4e056a2e044f3676df12 commons-collections4-4.3-bin.tar.gz OK. 706a0f5b4ddfd85e5444933576ea37776219748973bf4fc3944d846823f79395 commons-collections4-4.3-bin.zip 7a18a39b8b24d8688400276388d5c63da448ee7a8166561a5cffb617b952ed96 commons-collections4-4.3-src.tar.gz OK. 8a7b3ccd3fb2ba7edde7e08aa7606b3eacef260eab887358c56473a9e395067a commons-collections4-4.3-src.zip KEYS file to check signatures: https://www.apache.org/dist/commons/KEYS Maven artifacts: https://repository.apache.org/content/repositories/orgapachecommons-1401/ Please select one of the following options: [ ] +1 Release it. [ ] +0 Go ahead; I don't care. [ ] -0 There are a few minor glitches: ... [ ] -1 No, do not release it because ... This vote will be open for at least 72 hours, i.e. until 2018-12-22T14:00:00Z (this is UTC time). Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All][RNG] Fixing the download page
On Wed, 19 Dec 2018 15:11:59 +, sebb wrote: On Wed, 19 Dec 2018 at 14:50, Gilles wrote: On Wed, 19 Dec 2018 09:48:30 +, sebb wrote: > On Wed, 19 Dec 2018 at 00:05, Gilles > wrote: >> >> On Mon, 17 Dec 2018 15:28:46 +0100, Gilles wrote: >> > Ping? >> >> I found this: >> >> >> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commitdiff;h=f73546863611e5dd850fd311277f2019259489ce;hp=288c8b5196ab29e0e2ca50182a28f217e0828833 >> >> Please confirm whether the fix is "manual". > > Not sure what you mean by that. I mean that the release plugin does not regenerate the "download.xml" page (whereas this is typically a task that can be automated). Patches no doubt welcome to fix the plugin and its docs. > > AFAIK the fix listed above has yet to be included in the release of > commons-build plugin. > Someone needs to release 1.10 > > In the meantime, to use 1.10-SNAPSHOT you can use a command of the > form: > > $ mvn > org.apache.commons:commons-build-plugin:1.10-SNAPSHOT:download-page > > Add -Dcommons.release.version=m.n.o to override the pom version if > necessary. Thanks; that's what I missed. Just tried and... two problems: 1. The snapshot does not seem to be available from the usual place (Should it be generated by Jenkins?); I had to build the plugin and "install" it locally. Yes, forgot about that. 2. Running the above results in an error: ---CUT--- [ERROR] Failed to execute goal org.apache.commons:commons-build-plugin:1.10-SNAPSHOT:download-page (default-cli) on project commons-rng: Failed to execute: Executing Ant script: generate-xdocs.build.xml [download-page]: Failed to execute.: The following error occurred while executing this line: [ERROR] /tmp/plexus-ant-component10719660622814449892.build.xml:215: Unable to create javax script engine for javascript ---CUT--- [Note: this is on Java 9 and Java 10; on Java 8 it works fine.] OK, so that needs a bug report against the plugin (and patch if possible). > Since the commons build plugin is only used to automate editing the > download source file it does not matter whether you use a SNAPSHOT or > edit the file manually. Whatever gets the job done. Sure. Even "manual" is fine as long as we are not mislead top believe that this is taken of care of automatically. If the docs are misleading, then raise a bug and/or provide patches to the documentation. The step-by-step release recipe detailed in the "doc" directory of "Commons RNG" had worked flawlessly for its v1.0 release. But then for the v1.1 release (done by Rob, with the release-plugin) some steps became outdated, with some of their replacement not fully working (as I've detailed in other threads), manual tweaks had to be done, but are nowhere documented; this is understandable since the plugin is in development; but what is less, is that the release process was broken for some components (namely "Commons RNG"), and contrary to what you wrote several times, there was no easy way back (i.e. downgrading CP) because the component's POM relied on CP for common configuration necessary to fix general problems. In that case raise a bug for CP and/or provide patches. >> Gilles >> >> > >> > Is this a "release-plugin" bug to report on JIRA (COMMONSSITE), >> > or a usage issue? > > The download plugin is basically a script to automate maintenance of > the download.xml source file. > > AFAIK it has nothing to do with the release plugin. I meant that the output of the build plugin cannot affect the release plugin if the latter does not invoke the former. IMO, it has (cf. above); it does not make sense to prepare an RC with a wrong "download" page since it's likely to be a blocker (during the vote, or ... at the announcement). As noted above, raise a bug/enhancement if the release plugin should do more. > > Except of course you need ensure the download xml file is correct > before starting the release. I do not agree; For as long as I've been here, the advice (documented) has been: "Run this command [...] to regenerate the download page". Huh? That is still the case. And AFAIK that is what I wrote. The "command" above is the one in the template file i.e. mvn commons-build:download-page [copied from the "meta-template" file which you've just modified.] This is generating the page with SHA-1 and not SHA-256; so, no, it's not working currently (unless one knows it, and knows that a SNAPSHOT exists with the fix, and knows that one must install it locally and invoke it differently). Bug is in the "Commons" procedure where a required tool stopped behaving according to requirements (that a
Re: [VOTE][RC1] Commons collections 4.3
On Wed, 19 Dec 2018 23:08:44 +0700, Maxim Solodovnik wrote:
Thanks for checking Gilles,
Regarding clirr errors instruction states [1] to check errors only
for
minor release
Since it is 4.3.0 and not 4.2.1 I thought it is OK ..
4.X is a minor release ("Y.0" is a major one).
Usually (with no other explanation), this would be a blocker.
There was a change of supported platform (Java 7 -> 8)...
How this should be properly addressed?
release_4_3.html was not genarated during build :( How can I generate
it?
No, indeed.
It comes from a copy of the "RELEASE-NOTES.txt" that's at the
top-level.
But this is not blocker (site can be updated at any time).
Regards,
Gilles
Is it possible to perform site re-generation and maybe manual update
of apache-dev?
I will be OOO Thu-Sun, so will resolve all issues on return
[1]
https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=blob;f=doc/release/release.howto.txt#l73
On Wed, 19 Dec 2018 at 21:59, Gilles
wrote:
Hi.
Congratulations for getting that far in a fairly short time. ;-)
The BC report (Clirr) notes several incompatible changes:
https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC1/site/clirr-report.html
[No idea whether that was expected. If so, perhaps there should be
a remark in the release notes?]
In the site, the link to the release note is dead:
https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC1/site/release_4_3.html
[File must be copied manually (?). It does not seem to be at same
place
in "Collections" and in "RNG"!]
On Wed, 19 Dec 2018 20:41:15 +0700, Maxim Solodovnik wrote:
> This is a [VOTE] for releasing
> Apache Commons collections 4.3
>
> Tag name:
> collections-4.3-RC1 (signature can be checked from git using 'git
tag
> -v')
OK.
> Tag URL:
>
>
>
https://gitbox.apache.org/repos/asf?p=commons-collections.git;a=commit;h=5f959fd8e77bf28f6286cfb4d1e1fff27167f803
>
> Commit ID the tag points at:
> 5f959fd8e77bf28f6286cfb4d1e1fff27167f803
OK.
>
> Site:
>
>
>
https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC1/site/index.html
Download page will be wrong (cf. other thread with subject "Fixing
the download page).
>
> Distribution files (committed at revision 31605):
> https://dist.apache.org/repos/dist/dev/commons/collections/
>
> Distribution files hashes (SHA256):
>
201e1d527c67643b4e75065e113006d0610e8bf5620b4e056a2e044f3676df12
> commons-collections4-4.3-bin.tar.gz
OK.
>
706a0f5b4ddfd85e5444933576ea37776219748973bf4fc3944d846823f79395
> commons-collections4-4.3-bin.zip
>
7a18a39b8b24d8688400276388d5c63da448ee7a8166561a5cffb617b952ed96
> commons-collections4-4.3-src.tar.gz
OK.
>
8a7b3ccd3fb2ba7edde7e08aa7606b3eacef260eab887358c56473a9e395067a
> commons-collections4-4.3-src.zip
>
> KEYS file to check signatures:
> https://www.apache.org/dist/commons/KEYS
>
> Maven artifacts:
>
>
https://repository.apache.org/content/repositories/orgapachecommons-1401/
>
> Please select one of the following options:
> [ ] +1 Release it.
> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
>
> This vote will be open for at least 72 hours, i.e. until
> 2018-12-22T14:00:00Z
> (this is UTC time).
>
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[Release-plugin] Howto (Was: Help with migrating one of OpenJPA classes to commons-collections4)
Hello. On Wed, 19 Dec 2018 23:19:57 +0700, Maxim Solodovnik wrote: Hello Rob, The instruction [1] is good but seems to me "too universal" it would be easier to start with instruction specific to particular project :) I was my first release of commons-collections so I was unsure on every step :)) [1] https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=blob;f=doc/release/release.howto.txt Rob was probably talking about this page: http://commons.apache.org/proper/commons-release-plugin/index.html The reference [1] above is a recipe which I started to write for "Commons Math" way back when following any of the documents would get me stuck as I was tryiing to manage my first release. Through asking on the list, we manage to fill all the dots. Later, the "recipe" was adapted to "git" and then to "multimodule maven" (when I started "Commons RNG"). Regards, Gilles On Wed, 19 Dec 2018 at 21:19, Rob Tompkins wrote: > On Dec 19, 2018, at 8:29 AM, Maxim Solodovnik wrote: > > The build was successful > Staging repo is closed > > Thanks a lot for the help! How were the docs on using the release plugin? Just curious…as I wrote the plugin and the docs. -Rob [... lots of OT stuff skipped ...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng](site) broken source(current) link
Hi. On Thu, 20 Dec 2018 12:43:51 +, Bernd Eckenfels wrote: I wanted to check if RNG can construct uniformly distributed BigIntegers and how it is doing it (answer: it doesn’t) It could be a feature request. [I guess that you mean "within a given range".] Being curious: What's the use-case for random "BigInteger"s? while doing so I noticed that the site link to the source is broken, maybe this is due to git-wip migration? Yes. Thanks; fixed now. BTW: http://cr.openjdk.java.net/~bpb/8146153/webrev.01/index.html Regards, Gilles Gruss Bernd -- http://bernd.eckenfels.net - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Release-plugin][RNG] WIP? (Was: Fixing the download page)
On Wed, 19 Dec 2018 17:38:45 +, sebb wrote: On Wed, 19 Dec 2018 at 15:54, Gilles wrote: On Wed, 19 Dec 2018 15:11:59 +, sebb wrote: > On Wed, 19 Dec 2018 at 14:50, Gilles > wrote: >> >> On Wed, 19 Dec 2018 09:48:30 +, sebb wrote: >> > On Wed, 19 Dec 2018 at 00:05, Gilles >> >> > wrote: >> >> >> >> On Mon, 17 Dec 2018 15:28:46 +0100, Gilles wrote: >> >> > Ping? >> >> >> >> I found this: >> >> >> >> >> >> >> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commitdiff;h=f73546863611e5dd850fd311277f2019259489ce;hp=288c8b5196ab29e0e2ca50182a28f217e0828833 >> >> >> >> Please confirm whether the fix is "manual". >> > >> > Not sure what you mean by that. >> >> I mean that the release plugin does not regenerate the >> "download.xml" >> page (whereas this is typically a task that can be automated). > > Patches no doubt welcome to fix the plugin and its docs. > >> > >> > AFAIK the fix listed above has yet to be included in the release >> of >> > commons-build plugin. >> > Someone needs to release 1.10 >> > >> > In the meantime, to use 1.10-SNAPSHOT you can use a command of the >> > form: >> > >> > $ mvn >> > >> org.apache.commons:commons-build-plugin:1.10-SNAPSHOT:download-page >> > >> > Add -Dcommons.release.version=m.n.o to override the pom version if >> > necessary. >> >> Thanks; that's what I missed. >> >> Just tried and... two problems: >> 1. The snapshot does not seem to be available from the usual place >> (Should it be generated by Jenkins?); I had to build the plugin >> and "install" it locally. > > Yes, forgot about that. > >> 2. Running the above results in an error: >> ---CUT--- >> [ERROR] Failed to execute goal >> org.apache.commons:commons-build-plugin:1.10-SNAPSHOT:download-page >> (default-cli) on project commons-rng: Failed to execute: Executing >> Ant >> script: generate-xdocs.build.xml [download-page]: Failed to >> execute.: >> The following error occurred while executing this line: >> [ERROR] /tmp/plexus-ant-component10719660622814449892.build.xml:215: >> Unable to create javax script engine for javascript >> ---CUT--- >> [Note: this is on Java 9 and Java 10; on Java 8 it works fine.] > > OK, so that needs a bug report against the plugin (and patch if > possible). > >> > Since the commons build plugin is only used to automate editing >> the >> > download source file it does not matter whether you use a SNAPSHOT >> or >> > edit the file manually. Whatever gets the job done. >> >> Sure. Even "manual" is fine as long as we are not mislead top >> believe that this is taken of care of automatically. > > If the docs are misleading, then raise a bug and/or provide patches > to > the documentation. > >> The step-by-step release recipe detailed in the "doc" directory >> of "Commons RNG" had worked flawlessly for its v1.0 release. >> But then for the v1.1 release (done by Rob, with the release-plugin) >> some steps became outdated, with some of their replacement not fully >> working (as I've detailed in other threads), manual tweaks had to >> be done, but are nowhere documented; this is understandable since >> the plugin is in development; but what is less, is that the release >> process was broken for some components (namely "Commons RNG"), and >> contrary to what you wrote several times, there was no easy way back >> (i.e. downgrading CP) because the component's POM relied on CP for >> common configuration necessary to fix general problems. > > In that case raise a bug for CP and/or provide patches. > >> >> Gilles >> >> >> >> > >> >> > Is this a "release-plugin" bug to report on JIRA (COMMONSSITE), >> >> > or a usage issue? >> > >> > The download plugin is basically a script to automate maintenance >> of >> > the download.xml source file. >> > >> > AFAIK it has nothing to do with the release plugin. >> > > I meant that the output of the build plugin cannot affect the release > plugin if the latter does not invoke the former. > >> IMO, it has (cf. above); it does not make sense to prepare an RC >> with a wrong "download" page since it's likely to be a
Re: [VOTE][RC1] Commons collections 4.3
On Thu, 20 Dec 2018 10:46:46 +0700, Maxim Solodovnik wrote: My bad, Here is the analysis (please correct me if I'm wrong) Errors: [...] these errors are weird. Above classes has no changes comparing to 4.2 [1] It might the same problem which I've encountered a few eeks ago: Try to delete your local maven cache (i.e. all the subdirectories of "~/.m2" that refer to "collections"). HTH, Gilles [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng] Uniform big integers
Hi.
On Thu, 20 Dec 2018 15:15:55 +, Bernd Eckenfels wrote:
Hello,
I don’t know what the usecase is, it is motivated by a Bug about
BigInteger(num, Random). I guess one of the users is actually the
crypto usecase (starting with random numbers to find primes).
I wanted to check how RNG deals with this
You can do it by defining a bridge from [RNG] "UniformRandomProvider"
to "java.util.Random":
--- CUT (untested) ---
public class BridgeToRandom extends Random {
private final UniformRandomProvider delegate;
public BridgeToRandom(UniformRandomProvider rng) {
delegate = rng;
}
@Override
protected int next(int unused) {
return rng.nextInt();
}
}
---CUT---
Then, you can test all the generators implemented in [RNG].
Regards,
Gilles
(since the additional need
for generating a random bitlength looks unfamiliar but logical to
me).
Is it really not enough to fill all bits randomly (especially for the
case where it is a 0 .. 2^n range only)?
Discussion is here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057594.html
Gruss
Bernd
--
http://bernd.eckenfels.net
____
Von: Gilles
Gesendet: Donnerstag, Dezember 20, 2018 2:16 PM
An: dev@commons.apache.org
Betreff: Re: [rng](site) broken source(current) link
Hi.
On Thu, 20 Dec 2018 12:43:51 +, Bernd Eckenfels wrote:
I wanted to check if RNG can construct uniformly distributed
BigIntegers and how it is doing it (answer: it doesn’t)
It could be a feature request.
[I guess that you mean "within a given range".]
Being curious: What's the use-case for random "BigInteger"s?
while doing so
I noticed that the site link to the source is broken, maybe this is
due to git-wip migration?
Yes.
Thanks; fixed now.
BTW: http://cr.openjdk.java.net/~bpb/8146153/webrev.01/index.html
Regards,
Gilles
Gruss
Bernd
--
http://bernd.eckenfels.net
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng] Uniform big integers
On Thu, 20 Dec 2018 17:30:44 +0100, Gilles wrote:
Hi.
On Thu, 20 Dec 2018 15:15:55 +, Bernd Eckenfels wrote:
Hello,
I don’t know what the usecase is, it is motivated by a Bug about
BigInteger(num, Random). I guess one of the users is actually the
crypto usecase (starting with random numbers to find primes).
I wanted to check how RNG deals with this
You can do it by defining a bridge from [RNG] "UniformRandomProvider"
to "java.util.Random":
--- CUT (untested) ---
public class BridgeToRandom extends Random {
private final UniformRandomProvider delegate;
public BridgeToRandom(UniformRandomProvider rng) {
delegate = rng;
}
@Override
protected int next(int unused) {
return rng.nextInt();
}
}
---CUT---
Then, you can test all the generators implemented in [RNG].
FTR: In case you don't pursue it, please file a report on JIRA
to keep track of this if we want to explore how it could extend
the test suite.
Thanks,
Gilles
(since the additional need
for generating a random bitlength looks unfamiliar but logical to
me).
Is it really not enough to fill all bits randomly (especially for
the
case where it is a 0 .. 2^n range only)?
Discussion is here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057594.html
Gruss
Bernd
--
http://bernd.eckenfels.net
____
Von: Gilles
Gesendet: Donnerstag, Dezember 20, 2018 2:16 PM
An: dev@commons.apache.org
Betreff: Re: [rng](site) broken source(current) link
Hi.
On Thu, 20 Dec 2018 12:43:51 +, Bernd Eckenfels wrote:
I wanted to check if RNG can construct uniformly distributed
BigIntegers and how it is doing it (answer: it doesn’t)
It could be a feature request.
[I guess that you mean "within a given range".]
Being curious: What's the use-case for random "BigInteger"s?
while doing so
I noticed that the site link to the source is broken, maybe this is
due to git-wip migration?
Yes.
Thanks; fixed now.
BTW: http://cr.openjdk.java.net/~bpb/8146153/webrev.01/index.html
Regards,
Gilles
Gruss
Bernd
--
http://bernd.eckenfels.net
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng] Uniform big integers
Hi.
On Fri, 21 Dec 2018 16:04:05 +, Bernd Eckenfels wrote:
Hello,
The actual discussion on the OpenJDK list turned out to be a wrong
understanding and the simple case of generating random bytes was
enough for BigInteger.
However regarding RNG I can open requests, one would be for a
RandomAdapter and the other would be to add a factory method for
BigInteger (and possibly BigDecimal) to the Random Providers. (Or
did.
You mean only the Adapter?)
I actually meant testing whether the bug you mentioned could
be seen with an RNG other than "java.util.Random". But since
(IIUC) there is no bug...
Adapter/Bridge cannot fulfill all the functionality of "Random"
(e.g., there is, intentionally, no "setSeed" method).
It's a can of worms/issues with no decent workaround.[1]
So better leave that to application developers: The bridge itself
is trivial[2]; then they must be aware of what to implement,
depending on what the code (to which they pass the adapter) is
doing with it.
Generating "BigInteger" is at a level higher than the rest of the
core API (i.e. "UniformRandomProvider"), which is meant to generate
primitive types.[3]
At first sight, I'd put that functionality in another module.
Regards,
Gilles
[1]
http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html
[2] We might insert a paragraph about this in the userguide, and/or
provide the code snippet in the "commons-rng-examples" module.
[3]
http://commons.apache.org/proper/commons-rng/commons-rng-client-api/apidocs/org/apache/commons/rng/RestorableUniformRandomProvider.html
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Gilles
Gesendet: Freitag, Dezember 21, 2018 4:43 PM
An: dev@commons.apache.org
Betreff: Re: [rng] Uniform big integers
On Thu, 20 Dec 2018 17:30:44 +0100, Gilles wrote:
Hi.
On Thu, 20 Dec 2018 15:15:55 +, Bernd Eckenfels wrote:
Hello,
I don’t know what the usecase is, it is motivated by a Bug about
BigInteger(num, Random). I guess one of the users is actually the
crypto usecase (starting with random numbers to find primes).
I wanted to check how RNG deals with this
You can do it by defining a bridge from [RNG]
"UniformRandomProvider"
to "java.util.Random":
--- CUT (untested) ---
public class BridgeToRandom extends Random {
private final UniformRandomProvider delegate;
public BridgeToRandom(UniformRandomProvider rng) {
delegate = rng;
}
@Override
protected int next(int unused) {
return rng.nextInt();
}
}
---CUT---
Then, you can test all the generators implemented in [RNG].
FTR: In case you don't pursue it, please file a report on JIRA
to keep track of this if we want to explore how it could extend
the test suite.
Thanks,
Gilles
(since the additional need
for generating a random bitlength looks unfamiliar but logical to
me).
Is it really not enough to fill all bits randomly (especially for
the
case where it is a 0 .. 2^n range only)?
Discussion is here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057594.html
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Gilles
Gesendet: Donnerstag, Dezember 20, 2018 2:16 PM
An: dev@commons.apache.org
Betreff: Re: [rng](site) broken source(current) link
Hi.
On Thu, 20 Dec 2018 12:43:51 +, Bernd Eckenfels wrote:
I wanted to check if RNG can construct uniformly distributed
BigIntegers and how it is doing it (answer: it doesn’t)
It could be a feature request.
[I guess that you mean "within a given range".]
Being curious: What's the use-case for random "BigInteger"s?
while doing so
I noticed that the site link to the source is broken, maybe this
is
due to git-wip migration?
Yes.
Thanks; fixed now.
BTW: http://cr.openjdk.java.net/~bpb/8146153/webrev.01/index.html
Regards,
Gilles
Gruss
Bernd
--
http://bernd.eckenfels.net
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: AW: [rng] Uniform big integers
On Sat, 22 Dec 2018 00:51:11 +0100, Bernd Eckenfels wrote:
Hello,
just noticed an adapter is already referenced
(rng.simple.JDKRandomBridge)
Forgot that one; sorry!
Thanks for the reminder; "setSeed" is even supported...
Regards,
Gilles
on the „why not java random“ page. So it
can be used with the BigInteger constructor to generate power-of-two
randoms (already).
I wont request more Features without having a usecase for them.
Thanks for Looking into this.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Gilles
Gesendet: Samstag, 22. Dezember 2018 00:35
An: dev@commons.apache.org
Betreff: Re: [rng] Uniform big integers
Hi.
On Fri, 21 Dec 2018 16:04:05 +, Bernd Eckenfels wrote:
Hello,
The actual discussion on the OpenJDK list turned out to be a wrong
understanding and the simple case of generating random bytes was
enough for BigInteger.
However regarding RNG I can open requests, one would be for a
RandomAdapter and the other would be to add a factory method for
BigInteger (and possibly BigDecimal) to the Random Providers. (Or
did.
You mean only the Adapter?)
I actually meant testing whether the bug you mentioned could
be seen with an RNG other than "java.util.Random". But since
(IIUC) there is no bug...
Adapter/Bridge cannot fulfill all the functionality of "Random"
(e.g., there is, intentionally, no "setSeed" method).
It's a can of worms/issues with no decent workaround.[1]
So better leave that to application developers: The bridge itself
is trivial[2]; then they must be aware of what to implement,
depending on what the code (to which they pass the adapter) is
doing with it.
Generating "BigInteger" is at a level higher than the rest of the
core API (i.e. "UniformRandomProvider"), which is meant to generate
primitive types.[3]
At first sight, I'd put that functionality in another module.
Regards,
Gilles
[1]
http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html
[2] We might insert a paragraph about this in the userguide, and/or
provide the code snippet in the "commons-rng-examples" module.
[3]
http://commons.apache.org/proper/commons-rng/commons-rng-client-api/apidocs/org/apache/commons/rng/RestorableUniformRandomProvider.html
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Gilles
Gesendet: Freitag, Dezember 21, 2018 4:43 PM
An: dev@commons.apache.org
Betreff: Re: [rng] Uniform big integers
On Thu, 20 Dec 2018 17:30:44 +0100, Gilles wrote:
Hi.
On Thu, 20 Dec 2018 15:15:55 +, Bernd Eckenfels wrote:
Hello,
I don’t know what the usecase is, it is motivated by a Bug about
BigInteger(num, Random). I guess one of the users is actually the
crypto usecase (starting with random numbers to find primes).
I wanted to check how RNG deals with this
You can do it by defining a bridge from [RNG]
"UniformRandomProvider"
to "java.util.Random":
--- CUT (untested) ---
public class BridgeToRandom extends Random {
private final UniformRandomProvider delegate;
public BridgeToRandom(UniformRandomProvider rng) {
delegate = rng;
}
@Override
protected int next(int unused) {
return rng.nextInt();
}
}
---CUT---
Then, you can test all the generators implemented in [RNG].
FTR: In case you don't pursue it, please file a report on JIRA
to keep track of this if we want to explore how it could extend
the test suite.
Thanks,
Gilles
(since the additional need
for generating a random bitlength looks unfamiliar but logical to
me).
Is it really not enough to fill all bits randomly (especially for
the
case where it is a 0 .. 2^n range only)?
Discussion is here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057594.html
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Gilles
Gesendet: Donnerstag, Dezember 20, 2018 2:16 PM
An: dev@commons.apache.org
Betreff: Re: [rng](site) broken source(current) link
Hi.
On Thu, 20 Dec 2018 12:43:51 +, Bernd Eckenfels wrote:
I wanted to check if RNG can construct uniformly distributed
BigIntegers and how it is doing it (answer: it doesn’t)
It could be a feature request.
[I guess that you mean "within a given range".]
Being curious: What's the use-case for random "BigInteger"s?
while doing so
I noticed that the site link to the source is broken, maybe this
is
due to git-wip migration?
Yes.
Thanks; fixed now.
BTW: http://cr.openjdk.java.net/~bpb/8146153/webrev.01/index.html
Regards,
Gilles
Gruss
Bernd
--
http://bernd.eckenfels.net
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][RC1] Commons collections 4.3
On Mon, 24 Dec 2018 22:11:11 +0700, Maxim Solodovnik wrote:
Hello All,
I'm back :)
Shall I try to regenerate clirr report? and upload release_4_3.html?
Personally, I'd redo all the steps needed to ensure
consistency of what is used to create the release
but YMMV (and others may confirm that the above will
be fine).
According to download page: it seems `mvn
org.apache.commons:commons-build-plugin:1.10-SNAPSHOT:download-page`
does nothing for me
Works here.
But it seems there is a big mix-up in the POM with
the "commons.release..version" properties (comment
does not match the property name and value).
And the generated template of the download page contains
at least one undefined property:
${commons.release.4.binary.suffix}
Shall I manually update download page? What need to be updated?
Personally, I would not do it; IMHO, the POM needs fixing.
Best regards,
Gilles
On Fri, 21 Dec 2018 at 01:17, Gary Gregory
wrote:
Hi all, I am unable to review for at least 3 or 4 days. I am on the
road
and my laptop just died...
Gary
On Wed, Dec 19, 2018, 08:41 Maxim Solodovnik wrote:
> commons-collections4-4.3-src.zip.sha256This is a [VOTE] for
releasing
> Apache Commons collections 4.3
>
> Tag name:
> collections-4.3-RC1 (signature can be checked from git using 'git
tag -v')
>
> Tag URL:
>
>
https://gitbox.apache.org/repos/asf?p=commons-collections.git;a=commit;h=5f959fd8e77bf28f6286cfb4d1e1fff27167f803
>
> Commit ID the tag points at:
> 5f959fd8e77bf28f6286cfb4d1e1fff27167f803
>
> Site:
>
>
https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC1/site/index.html
>
> Distribution files (committed at revision 31605):
> https://dist.apache.org/repos/dist/dev/commons/collections/
>
> Distribution files hashes (SHA256):
>
201e1d527c67643b4e75065e113006d0610e8bf5620b4e056a2e044f3676df12
> commons-collections4-4.3-bin.tar.gz
>
706a0f5b4ddfd85e5444933576ea37776219748973bf4fc3944d846823f79395
> commons-collections4-4.3-bin.zip
>
7a18a39b8b24d8688400276388d5c63da448ee7a8166561a5cffb617b952ed96
> commons-collections4-4.3-src.tar.gz
>
8a7b3ccd3fb2ba7edde7e08aa7606b3eacef260eab887358c56473a9e395067a
> commons-collections4-4.3-src.zip
>
> KEYS file to check signatures:
> https://www.apache.org/dist/commons/KEYS
>
> Maven artifacts:
>
>
https://repository.apache.org/content/repositories/orgapachecommons-1401/
>
> Please select one of the following options:
> [ ] +1 Release it.
> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
>
> This vote will be open for at least 72 hours, i.e. until
> 2018-12-22T14:00:00Z
> (this is UTC time).
>
>
-
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
--
WBR
Maxim aka solomax
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][RC1] Commons collections 4.3
On Tue, 25 Dec 2018 01:15:23 +0100, Gilles wrote:
On Mon, 24 Dec 2018 22:11:11 +0700, Maxim Solodovnik wrote:
Hello All,
I'm back :)
Shall I try to regenerate clirr report? and upload release_4_3.html?
Personally, I'd redo all the steps needed to ensure
consistency of what is used to create the release
but YMMV (and others may confirm that the above will
be fine).
Also, I've just noticed that in the "4.3-release" branch,
the POM still refers to "4.3-SNAPSHOT" whereas it should
have been changed to "4.3". [That's the primary reason
for creating that branch.]
You should also update the properties used by the release
plugin (RM's name and GPG key, etc).
According to download page: it seems `mvn
org.apache.commons:commons-build-plugin:1.10-SNAPSHOT:download-page`
does nothing for me
Works here.
Means: it creates the template file that will be used by the
"site" goal to generate the HTML page.
Regards,
Gilles
But it seems there is a big mix-up in the POM with
the "commons.release..version" properties (comment
does not match the property name and value).
And the generated template of the download page contains
at least one undefined property:
${commons.release.4.binary.suffix}
Shall I manually update download page? What need to be updated?
Personally, I would not do it; IMHO, the POM needs fixing.
Best regards,
Gilles
On Fri, 21 Dec 2018 at 01:17, Gary Gregory
wrote:
Hi all, I am unable to review for at least 3 or 4 days. I am on the
road
and my laptop just died...
Gary
On Wed, Dec 19, 2018, 08:41 Maxim Solodovnik wrote:
> commons-collections4-4.3-src.zip.sha256This is a [VOTE] for
releasing
> Apache Commons collections 4.3
>
> Tag name:
> collections-4.3-RC1 (signature can be checked from git using 'git
tag -v')
>
> Tag URL:
>
>
https://gitbox.apache.org/repos/asf?p=commons-collections.git;a=commit;h=5f959fd8e77bf28f6286cfb4d1e1fff27167f803
>
> Commit ID the tag points at:
> 5f959fd8e77bf28f6286cfb4d1e1fff27167f803
>
> Site:
>
>
https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC1/site/index.html
>
> Distribution files (committed at revision 31605):
> https://dist.apache.org/repos/dist/dev/commons/collections/
>
> Distribution files hashes (SHA256):
>
201e1d527c67643b4e75065e113006d0610e8bf5620b4e056a2e044f3676df12
> commons-collections4-4.3-bin.tar.gz
>
706a0f5b4ddfd85e5444933576ea37776219748973bf4fc3944d846823f79395
> commons-collections4-4.3-bin.zip
>
7a18a39b8b24d8688400276388d5c63da448ee7a8166561a5cffb617b952ed96
> commons-collections4-4.3-src.tar.gz
>
8a7b3ccd3fb2ba7edde7e08aa7606b3eacef260eab887358c56473a9e395067a
> commons-collections4-4.3-src.zip
>
> KEYS file to check signatures:
> https://www.apache.org/dist/commons/KEYS
>
> Maven artifacts:
>
>
https://repository.apache.org/content/repositories/orgapachecommons-1401/
>
> Please select one of the following options:
> [ ] +1 Release it.
> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
>
> This vote will be open for at least 72 hours, i.e. until
> 2018-12-22T14:00:00Z
> (this is UTC time).
>
>
-
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
--
WBR
Maxim aka solomax
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][RC1] Commons collections 4.3
Hi.
On Tue, 25 Dec 2018 22:22:43 +0700, Maxim Solodovnik wrote:
Hello Gilles,
Actually if release is made based on git it is not necessary to
perform commits
?
I don't know other ways to perform the release; I follow
the practice established for "svn", that was then adapted
for "git" when we switched to it.
Do you propose an alternative way to do it? Please
share some link describing the process
into local branch you are using to create RC tag
this why I previously ask if I can drop useless branch
In the current scheme, it does not seem useless... ;-)
I can fix issues with site manually, but it will be impossible to
modify pom without canceling release
I totally miss these properties :(
I think that you can specify the values on the command
line too.
Shall I cancel the VOTE and create RC2?
It's up to you. Personally, I'd take the safest way to
ensure an RC with no issues.
Regards,
Gilles
On Tue, 25 Dec 2018 at 07:48, Gilles
wrote:
On Tue, 25 Dec 2018 01:15:23 +0100, Gilles wrote:
> On Mon, 24 Dec 2018 22:11:11 +0700, Maxim Solodovnik wrote:
>> Hello All,
>>
>> I'm back :)
>> Shall I try to regenerate clirr report? and upload
release_4_3.html?
>
> Personally, I'd redo all the steps needed to ensure
> consistency of what is used to create the release
> but YMMV (and others may confirm that the above will
> be fine).
Also, I've just noticed that in the "4.3-release" branch,
the POM still refers to "4.3-SNAPSHOT" whereas it should
have been changed to "4.3". [That's the primary reason
for creating that branch.]
You should also update the properties used by the release
plugin (RM's name and GPG key, etc).
>
>>
>> According to download page: it seems `mvn
>>
org.apache.commons:commons-build-plugin:1.10-SNAPSHOT:download-page`
>> does nothing for me
>
> Works here.
Means: it creates the template file that will be used by the
"site" goal to generate the HTML page.
Regards,
Gilles
> But it seems there is a big mix-up in the POM with
> the "commons.release..version" properties (comment
> does not match the property name and value).
> And the generated template of the download page contains
> at least one undefined property:
> ${commons.release.4.binary.suffix}
>
>> Shall I manually update download page? What need to be updated?
>
> Personally, I would not do it; IMHO, the POM needs fixing.
>
> Best regards,
> Gilles
>
>>
>> On Fri, 21 Dec 2018 at 01:17, Gary Gregory
>> wrote:
>>>
>>> Hi all, I am unable to review for at least 3 or 4 days. I am on
the
>>> road
>>> and my laptop just died...
>>>
>>> Gary
>>>
>>> On Wed, Dec 19, 2018, 08:41 Maxim Solodovnik >> wrote:
>>>
>>> > commons-collections4-4.3-src.zip.sha256This is a [VOTE] for
>>> releasing
>>> > Apache Commons collections 4.3
>>> >
>>> > Tag name:
>>> > collections-4.3-RC1 (signature can be checked from git using
'git
>>> tag -v')
>>> >
>>> > Tag URL:
>>> >
>>> >
>>>
https://gitbox.apache.org/repos/asf?p=commons-collections.git;a=commit;h=5f959fd8e77bf28f6286cfb4d1e1fff27167f803
>>> >
>>> > Commit ID the tag points at:
>>> > 5f959fd8e77bf28f6286cfb4d1e1fff27167f803
>>> >
>>> > Site:
>>> >
>>> >
>>>
https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC1/site/index.html
>>> >
>>> > Distribution files (committed at revision 31605):
>>> >
https://dist.apache.org/repos/dist/dev/commons/collections/
>>> >
>>> > Distribution files hashes (SHA256):
>>> >
>>> 201e1d527c67643b4e75065e113006d0610e8bf5620b4e056a2e044f3676df12
>>> > commons-collections4-4.3-bin.tar.gz
>>> >
>>> 706a0f5b4ddfd85e5444933576ea37776219748973bf4fc3944d846823f79395
>>> > commons-collections4-4.3-bin.zip
>>> >
>>> 7a18a39b8b24d8688400276388d5c63da448ee7a8166561a5cffb617b952ed96
>>> > commons-collections4-4.3-src.tar.gz
>>> >
>>> 8a7b3ccd3fb2ba7edde7e08aa7606b3eacef260eab887358c56473a9e395067a
>>> > commons-collections4-4.3-src.zip
>>> >
>>> > KEYS file to check signatures:
>>> > https://www.apache.org/dist/commons/KEYS
>>> >
>>> > Maven artifacts:
>>> >
>>> >
>>>
https://repository.apache.org/content/repositories/orgapachecommons-1401/
>>> >
>>> > Please select one of the following options:
>>> > [ ] +1 Release it.
>>> > [ ] +0 Go ahead; I don't care.
>>> > [ ] -0 There are a few minor glitches: ...
>>> > [ ] -1 No, do not release it because ...
>>> >
>>> > This vote will be open for at least 72 hours, i.e. until
>>> > 2018-12-22T14:00:00Z
>>> > (this is UTC time).
>>> >
>>> >
>>>
-
>>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> > For additional commands, e-mail: dev-h...@commons.apache.org
>>> >
>>> >
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][RC1] Commons collections 4.3
Hi. On Wed, 26 Dec 2018 08:23:03 +0700, Maxim Solodovnik wrote: This is the way Wicketstuff build is performed [1] The project consist of ~285 modules and it is wise to create tag only if build is already in Nexus :) [1] https://github.com/wicketstuff/core/wiki/Wicket-Stuff-Core-Release-Process I get it now! So indeed, a "release" branch that is pushed upstream is not necessary.[1] And there is another couple of improvements which I could use next time. Thanks for sharing, Gilles [1] It might become useful only if the RC has problems _and_ other people want to help with fixing (?). On Wed, 26 Dec 2018 at 08:11, Rob Tompkins wrote: > On Dec 25, 2018, at 8:04 PM, Maxim Solodovnik wrote: > > In both git and svn you need a branch to create tag > But since git has local and remote repository, steps can be: > > 1) create local branch > 2) made "release" changes > 3) create tag > 4) push the tag > > In this case only tag will be pushed, and there will be no useless branches > with minimal "release" changes > Yes that is true. But so long as the vote has yet to be initiated, the tag can be pushed even after the build has been made. -Rob >> On Wed, 26 Dec 2018 at 05:40, Gilles wrote: >> >> Hi. >> >>> On Tue, 25 Dec 2018 22:22:43 +0700, Maxim Solodovnik wrote: >>> Hello Gilles, >>> >>> Actually if release is made based on git it is not necessary to >>> perform commits >> >> ? >> I don't know other ways to perform the release; I follow >> the practice established for "svn", that was then adapted >> for "git" when we switched to it. >> >> Do you propose an alternative way to do it? Please >> share some link describing the process >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][RC2] Commons collections 4.3
Hi. On Wed, 26 Dec 2018 20:41:59 +0700, Maxim Solodovnik wrote: This is a [VOTE] for releasing Apache Commons collections 4.3 Tag name: collections-4.3-RC2 (signature can be checked from git using 'git tag -v') $ git tag -v collections-4.3-RC2 error: tag 'collections-4.3-RC2' not found. Although I see it in the link below... What is going on? RC1 was cancelled due to some release steps were not done Tag URL: https://gitbox.apache.org/repos/asf?p=commons-collections.git;a=commit;h=77e37dbf238d26351edb29e95391e3df75095d01 Commit ID the tag points at: 77e37dbf238d26351edb29e95391e3df75095d01 Site: https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC2/site/index.html The Clirr report is still a problem: https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC2/site/clirr-report.html [The same errors are reported on my machine, so it's not a cache issue...] Regards, Gilles Distribution files (committed at revision 31689): https://dist.apache.org/repos/dist/dev/commons/collections/ Distribution files hashes (SHA256): commons-collections4-4.3-bin.tar.gz 214c12fae27403f1a16ca6c108b5a8682be1a885a0dbbfc8eb30941303e1fe94 commons-collections4-4.3-bin.zip 75b51a98fea6fca3746a3f70c6a0be24c99849e4976c4649214eaa5a009d0aeb commons-collections4-4.3-src.tar.gz 399f403feca86dbba7c4162eb90174db45979a2f7db2b3e0ba48240dc43ab434 commons-collections4-4.3-src.zip 1c637e260b5b9e372d196593c7617ad3adedb6da3ac9196d086f9fc24401f5c3 KEYS file to check signatures: https://www.apache.org/dist/commons/KEYS Maven artifacts: https://repository.apache.org/content/repositories/orgapachecommons-1405/ Please select one of the following options: [ ] +1 Release it. [ ] +0 Go ahead; I don't care. [ ] -0 There are a few minor glitches: ... [ ] -1 No, do not release it because ... This vote will be open for at least 72 hours, i.e. until 2018-12-29T14:00:00Z (this is UTC time). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][RC2] Commons collections 4.3
On Wed, 26 Dec 2018 21:21:34 +0100, Gilles wrote: Hi. On Wed, 26 Dec 2018 20:41:59 +0700, Maxim Solodovnik wrote: This is a [VOTE] for releasing Apache Commons collections 4.3 Tag name: collections-4.3-RC2 (signature can be checked from git using 'git tag -v') $ git tag -v collections-4.3-RC2 error: tag 'collections-4.3-RC2' not found. Although I see it in the link below... What is going on? Issue vanished with a fresh "clone". [Sorry for the noise.] RC1 was cancelled due to some release steps were not done Tag URL: https://gitbox.apache.org/repos/asf?p=commons-collections.git;a=commit;h=77e37dbf238d26351edb29e95391e3df75095d01 Commit ID the tag points at: 77e37dbf238d26351edb29e95391e3df75095d01 Site: https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC2/site/index.html The Clirr report is still a problem: https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC2/site/clirr-report.html [The same errors are reported on my machine, so it's not a cache issue...] Regards, Gilles Distribution files (committed at revision 31689): https://dist.apache.org/repos/dist/dev/commons/collections/ Distribution files hashes (SHA256): commons-collections4-4.3-bin.tar.gz 214c12fae27403f1a16ca6c108b5a8682be1a885a0dbbfc8eb30941303e1fe94 commons-collections4-4.3-bin.zip 75b51a98fea6fca3746a3f70c6a0be24c99849e4976c4649214eaa5a009d0aeb commons-collections4-4.3-src.tar.gz 399f403feca86dbba7c4162eb90174db45979a2f7db2b3e0ba48240dc43ab434 commons-collections4-4.3-src.zip 1c637e260b5b9e372d196593c7617ad3adedb6da3ac9196d086f9fc24401f5c3 KEYS file to check signatures: https://www.apache.org/dist/commons/KEYS Maven artifacts: https://repository.apache.org/content/repositories/orgapachecommons-1405/ Please select one of the following options: [ ] +1 Release it. [ ] +0 Go ahead; I don't care. [ ] -0 There are a few minor glitches: ... [ ] -1 No, do not release it because ... This vote will be open for at least 72 hours, i.e. until 2018-12-29T14:00:00Z (this is UTC time). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [numbers] propose making BigFraction an extension of Fraction
Hi Eric.
On Thu, 27 Dec 2018 11:53:39 -0800, Eric Barnhill wrote:
Thanks for this response and it took me some time to think your
various
points through.
On Thu, Dec 13, 2018 at 4:59 PM Gilles
wrote:
On Thu, 13 Dec 2018 11:20:12 -0800, Eric Barnhill wrote:
> Among the elegancies afforded by this change, if a Fraction
operation
> causes overflow as previously discussed, a BigFraction could be
> returned
> and should be able to handle all further calls to Fraction
unaltered.
> (This
> might not always be desired behavior, so Fraction may need to
contain
> a
> setting to either throw and exception, or convert to BigFraction
in
> case of
> overflow.)
Doesn't this setting achieve at runtime what the application
developer should decide at compile time (by instantiating the
class that has the desired behaviour)?
Yes. Perhaps I have been spending too much time writing Python
lately.
:-)
>
> So I propose writing a ticket for this change. As sub-points on
the
> ticket
> the BigFraction class could be conformed to Fraction class in
terms
> of
> reduction of constants and producing a VALJO.
Inheritance and ValJO turn out being contradictory (see thread
with subject "Inheritance and ValJO ?").
And (IIUC) the workaround/alternative hinted at by Stephen
in that same thread might not be directly applicable because,
here, the instance fields are different in "Fraction" and
"BigFraction" ("long" vs "BigInteger").
I've just noticed that "BigInteger" is not final; hence
"BigFraction" cannot be a ValJO either.[1]
It sounds like this is sufficient to disqualify this proposal.
I don't think that we should rule out a "Fraction" interface.
Maybe not.
How to call the implementations? "BigFraction" and ...
"SmallFraction"?
Since BigFraction and Fraction have the use cases covered for now
(improved, I would argue, by only the former requiring Big* classes)
I
propose wrapping up this work and leaving this until after a release.
Fine.
[1] So this issue:
https://issues.apache.org/jira/browse/NUMBERS-75
should probably be resolved as "Invalid".
Done.
Thanks.
But, there were some "peripheral" improvements that came out of
making Fraction a ValJO that should still be applied to BigFraction,
for
example conforming both classes to use the same factory methods,
+1
and
reducing the absurd number of BigFraction constants.
+1
Shall I reopen and
rename the ticket to focus on these changes, or is it better to start
a new
one?
I'd go for new one.
Best regards,
Gilles
Eric
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-numbers] branch fraction-dev updated: NUMBERS-91: Added ofInt() factory methods and made BigInteger-based constructor private
On Thu, 27 Dec 2018 23:54:57 +, ericbarnh...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. ericbarnhill pushed a commit to branch fraction-dev in repository https://gitbox.apache.org/repos/asf/commons-numbers.git The following commit(s) were added to refs/heads/fraction-dev by this push: new ebb8e03 NUMBERS-91: Added ofInt() factory methods Why not rely on method overload? There is no need to duplicate part of the the method's signature in its name. Gilles and made BigInteger-based constructor private ebb8e03 is described below commit ebb8e03f139b8cec84564b3e558fea39b71d2f24 Author: Eric Barnhill AuthorDate: Thu Dec 27 15:54:51 2018 -0800 NUMBERS-91: Added ofInt() factory methods and made BigInteger-based constructor private --- .../commons/numbers/fraction/BigFraction.java | 68 +++--- 1 file changed, 20 insertions(+), 48 deletions(-) [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-numbers] [...] NUMBERS-91: Added ofInt() factory methods [...]
Hello Eric.
On Thu, 27 Dec 2018 17:00:15 -0800, Eric Barnhill wrote:
I am overloading:
public static BigFraction ofInt(final BigInteger num) {
return new BigFraction(num, BigInteger.ONE);
}
public static BigFraction ofInt(BigInteger num, BigInteger den) {
return new BigFraction(num, den);
}
private BigFraction(BigInteger num, BigInteger den) {
Did my comment not give that impression?
I was in fact wondering why "ofInt" rather than just "of".
Best,
Gilles
[...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][LAZY] Move commons-codec to gitbox after 1.12 release.
On Fri, 28 Dec 2018 13:18:41 -0500, Rob Tompkins wrote: Yes. I agree that makes sense. It is a considerable amount of work to do that migration in a single go. So, I’m not sure if we should go at it piecemeal or as a complete lump of work. -Rob On Dec 28, 2018, at 11:41 AM, Jochen Wiedmann wrote: Weren't we going to fo that for *all* of our projects? I also did not understand the purpose of yet another vote. AFAIUC, the vote (for _all_ components) passed. Hence anyone with some time can file an INFRA request asking for the migration of a component of his choice. Or am I missing something? Gilles On Fri, Dec 28, 2018 at 4:17 PM Pascal Schumacher wrote: +1 Am 28.12.2018 um 15:51 schrieb Rob Tompkins: After doing the 1.12 release I propose we move commons-codec to gitbox. This is a [LAZY] consensus [VOTE] for doing such after I get through the release. This [LAZY][VOTE] will be open for at least 72 hours form now. Cheers, -Rob - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-numbers] [...] NUMBERS-91: Added ofInt() factory methods [...]
On Fri, 28 Dec 2018 09:17:08 -0800, Eric Barnhill wrote:
Fractions are constructed using either ints or doubles. In the case
of
ints, the numerator and denominator are passed (or the denominator is
assumed to be one). Constructing fractions from doubles is more
algorithmic
work: if I pass a known fixed quantity such as 0.6 of course it will
not be
hard for the constructor to determine that is the equivalent of 3 / 5
.
However if doubles are being passed of unknown precision, then I may
want
to request a max value on the denominator, or a precision within
which the
simplest fraction should be returned, or even the maximum iterations
in the
computation.
I think of those as qualitatively very different activities
I agree.
so I called
them ofInt and ofDouble.
But we could consider:
Cat.1
* of(long, long)
* of(int, long)
* of(BigInteger, BigInteger)
* ...
and
Cat.2
* ofDouble(double)
* ofDouble(int, double)
* ...
where "Cat.1" and "Cat.2" delineates the very different handling
which you referred to; and in the case of "Cat.1", an exact (?)
representation is constructed, while "Cat.2" could be lossy.
The former can also be construed as closer to the convention for
"ValJO" ("BigFaction" not being "ValJO" does not preclude choosing
the simplest name for its factory methods).
The example I had in mind was probably Complex,
where we have ofPolar and ofCartesian. I suppose you are right, in
this
case the hard typing of the passed variables alone could invoke
either an
int or double based method while with Complex, both constructors are
taking
doubles.
Quite right, there is some inconsistency; we may consider using
"of" if the "ValJO" aspect is more important that the equivalence
between polar and Cartesian input (cf. also the suggestion that
conversion methods should be name "from...", to which I'm not really
a fan yet).
If there is no strong argument yet for either, we could open a JIRA
report asking for opinions. And leave that open as long as we
release "beta" versions.
You do then have some very similar methods, for example of(int a, int
b)
will be an integer fraction with a on top and b on bottom; while
calling
of(double a, int b) will produce a fraction that approximates double
a with
max denominator b.
Those two processes are so different that it might be more clarifying
to
distinguish them as ofInt(int a, int b) and ofDouble(double a, int b)
IMHO, it is not sufficiently self-documenting anyway: one has to go
to the docs in order to understand the difference; hence my proposal
to have "of" for the "obvious thing" (a/b) and "ofDouble" for the more
elaborate "transform".
Not sure if I'm clear in why the "non-symmetric" makes sense. :-}
Best regards,
Gilles
Eric
On Fri, Dec 28, 2018 at 4:33 AM Gilles
wrote:
Hello Eric.
On Thu, 27 Dec 2018 17:00:15 -0800, Eric Barnhill wrote:
> I am overloading:
>
> public static BigFraction ofInt(final BigInteger num) {
> return new BigFraction(num, BigInteger.ONE);
> }
>
> public static BigFraction ofInt(BigInteger num, BigInteger
den) {
> return new BigFraction(num, den);
> }
>
> private BigFraction(BigInteger num, BigInteger den) {
>
> Did my comment not give that impression?
I was in fact wondering why "ofInt" rather than just "of".
Best,
Gilles
>> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][LAZY] Move commons-codec to gitbox after 1.12 release.
On Fri, 28 Dec 2018 14:00:48 -0500, Rob Tompkins wrote: On Dec 28, 2018, at 1:31 PM, Gilles wrote: On Fri, 28 Dec 2018 13:18:41 -0500, Rob Tompkins wrote: Yes. I agree that makes sense. It is a considerable amount of work to do that migration in a single go. So, I’m not sure if we should go at it piecemeal or as a complete lump of work. -Rob On Dec 28, 2018, at 11:41 AM, Jochen Wiedmann wrote: Weren't we going to fo that for *all* of our projects? I also did not understand the purpose of yet another vote. AFAIUC, the vote (for _all_ components) passed. Hence anyone with some time can file an INFRA request asking for the migration of a component of his choice. Or am I missing something? That last list of components were the components in git-wip that infra required us to move to gitbox. [codec] remains in SVN. I could have missed our having record of all components going to gitbox. Pardon if I did miss that. If we don’t have such a [VOTE] on all svn components, I’m quite happy to retract this [VOTE] en leu of that (and am willing to do the vote). If a vote is needed at all, I'd propose asking whether someone here insists on keeping any component on SVN, and if so, which one(s). Regards, Gilles -Rob Gilles On Fri, Dec 28, 2018 at 4:17 PM Pascal Schumacher wrote: +1 Am 28.12.2018 um 15:51 schrieb Rob Tompkins: After doing the 1.12 release I propose we move commons-codec to gitbox. This is a [LAZY] consensus [VOTE] for doing such after I get through the release. This [LAZY][VOTE] will be open for at least 72 hours form now. Cheers, -Rob - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][RC2] Commons collections 4.3
On Sun, 30 Dec 2018 12:25:55 +0700, Maxim Solodovnik wrote: No votes after 3 days :( Is there anything wrong with the RC? See my 4-days-old comment in the thread (Clirr errors). [Quoted below.] Regards, Gilles On Thu, 27 Dec 2018 at 05:20, Bruno P. Kinoshita wrote: FWIW I had a similar experience, and realized I was doing `git fetch --all`, but it didn't bring the tags. `git fetch --tags` did the trick. After that I could `git checkout $tag-name` Cheers Bruno From: Gilles To: dev@commons.apache.org Sent: Thursday, 27 December 2018 9:26 AM Subject: Re: [VOTE][RC2] Commons collections 4.3 On Wed, 26 Dec 2018 21:21:34 +0100, Gilles wrote: > Hi. > > On Wed, 26 Dec 2018 20:41:59 +0700, Maxim Solodovnik wrote: >> This is a [VOTE] for releasing >> Apache Commons collections 4.3 >> >> Tag name: >> collections-4.3-RC2 (signature can be checked from git using >> 'git >> tag -v') > > $ git tag -v collections-4.3-RC2 > error: tag 'collections-4.3-RC2' not found. > > Although I see it in the link below... > What is going on? Issue vanished with a fresh "clone". [Sorry for the noise.] >> RC1 was cancelled due to some release steps were not done >> >> Tag URL: >> >> >> https://gitbox.apache.org/repos/asf?p=commons-collections.git;a=commit;h=77e37dbf238d26351edb29e95391e3df75095d01 >> >> Commit ID the tag points at: >> 77e37dbf238d26351edb29e95391e3df75095d01 >> >> Site: >> >> >> https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC2/site/index.html > > The Clirr report is still a problem: > > > https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC2/site/clirr-report.html > > [The same errors are reported on my machine, so it's > not a cache issue...] > > Regards, > Gilles > >> >> Distribution files (committed at revision 31689): >>https://dist.apache.org/repos/dist/dev/commons/collections/ >> >> Distribution files hashes (SHA256): >> commons-collections4-4.3-bin.tar.gz >> 214c12fae27403f1a16ca6c108b5a8682be1a885a0dbbfc8eb30941303e1fe94 >> commons-collections4-4.3-bin.zip >> 75b51a98fea6fca3746a3f70c6a0be24c99849e4976c4649214eaa5a009d0aeb >> commons-collections4-4.3-src.tar.gz >> 399f403feca86dbba7c4162eb90174db45979a2f7db2b3e0ba48240dc43ab434 >> commons-collections4-4.3-src.zip >> 1c637e260b5b9e372d196593c7617ad3adedb6da3ac9196d086f9fc24401f5c3 >> >> KEYS file to check signatures: >>https://www.apache.org/dist/commons/KEYS >> >> Maven artifacts: >> >> https://repository.apache.org/content/repositories/orgapachecommons-1405/ >> >> Please select one of the following options: >> [ ] +1 Release it. >> [ ] +0 Go ahead; I don't care. >> [ ] -0 There are a few minor glitches: ... >> [ ] -1 No, do not release it because ... >> >> This vote will be open for at least 72 hours, i.e. until >> 2018-12-29T14:00:00Z >> (this is UTC time). >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][RC2] Commons collections 4.3
On Mon, 31 Dec 2018 07:41:40 +0700, Maxim Solodovnik wrote: Hello Gilles, I already did analysis: [1], all errors are caused by previous release 4.3 doesn't introduce any new errors ... [1] https://markmail.org/message/l7ftxlvdk4yqxijt I had seen the post but it says: --- these errors are weird. Above classes has no changes comparing to 4.2 --- But IMHO it was not a conclusion: If the cause of the errors was identified, it could have been mentioned in the release notes and/or the [VOTE] email, in order to avoid further questioning. Is the cause the change of supported JDK? Regards, Gilles On Mon, 31 Dec 2018 at 07:26, Rob Tompkins wrote: I’ll give it a look tonight or in the morning. -Rob > On Dec 30, 2018, at 12:25 AM, Maxim Solodovnik wrote: > > No votes after 3 days :( > Is there anything wrong with the RC? > >> On Thu, 27 Dec 2018 at 05:20, Bruno P. Kinoshita wrote: >> >> FWIW I had a similar experience, and realized I was doing `git fetch --all`, but it didn't bring the tags. `git fetch --tags` did the trick. After that I could `git checkout $tag-name` >> >> Cheers >> Bruno >> >> >> >> >> >> From: Gilles >> To: dev@commons.apache.org >> Sent: Thursday, 27 December 2018 9:26 AM >> Subject: Re: [VOTE][RC2] Commons collections 4.3 >> >> >> >>> On Wed, 26 Dec 2018 21:21:34 +0100, Gilles wrote: >>> Hi. >>> >>>> On Wed, 26 Dec 2018 20:41:59 +0700, Maxim Solodovnik wrote: >>>> This is a [VOTE] for releasing >>>> Apache Commons collections 4.3 >>>> >>>> Tag name: >>>>collections-4.3-RC2 (signature can be checked from git using >>>> 'git >>>> tag -v') >>> >>> $ git tag -v collections-4.3-RC2 >>> error: tag 'collections-4.3-RC2' not found. >>> >>> Although I see it in the link below... >>> What is going on? >> >> Issue vanished with a fresh "clone". >> [Sorry for the noise.] >> >> >>>> RC1 was cancelled due to some release steps were not done >>>> >>>> Tag URL: >>>> >>>> >>>> https://gitbox.apache.org/repos/asf?p=commons-collections.git;a=commit;h=77e37dbf238d26351edb29e95391e3df75095d01 >>>> >>>> Commit ID the tag points at: >>>>77e37dbf238d26351edb29e95391e3df75095d01 >>>> >>>> Site: >>>> >>>> >>>> https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC2/site/index.html >>> >>> The Clirr report is still a problem: >>> >>> >>> https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC2/site/clirr-report.html >>> >>> [The same errors are reported on my machine, so it's >>> not a cache issue...] >>> >>> Regards, >>> Gilles >>> >>>> >>>> Distribution files (committed at revision 31689): >>>> https://dist.apache.org/repos/dist/dev/commons/collections/ >>>> >>>> Distribution files hashes (SHA256): >>>> commons-collections4-4.3-bin.tar.gz >>>> 214c12fae27403f1a16ca6c108b5a8682be1a885a0dbbfc8eb30941303e1fe94 >>>> commons-collections4-4.3-bin.zip >>>> 75b51a98fea6fca3746a3f70c6a0be24c99849e4976c4649214eaa5a009d0aeb >>>> commons-collections4-4.3-src.tar.gz >>>> 399f403feca86dbba7c4162eb90174db45979a2f7db2b3e0ba48240dc43ab434 >>>> commons-collections4-4.3-src.zip >>>> 1c637e260b5b9e372d196593c7617ad3adedb6da3ac9196d086f9fc24401f5c3 >>>> >>>> KEYS file to check signatures: >>>> https://www.apache.org/dist/commons/KEYS >>>> >>>> Maven artifacts: >>>> >>>> https://repository.apache.org/content/repositories/orgapachecommons-1405/ >>>> >>>> Please select one of the following options: >>>> [ ] +1 Release it. >>>> [ ] +0 Go ahead; I don't care. >>>> [ ] -0 There are a few minor glitches: ... >>>> [ ] -1 No, do not release it because ... >>>> >>>> This vote will be open for at least 72 hours, i.e. until >>>> 2018-12-29T14:00:00Z >>>> (this is UTC time). >>>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > -- > WBR > Maxim aka solomax > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][RC2] Commons collections 4.3
Hello. On Wed, 2 Jan 2019 14:01:24 +0700, Maxim Solodovnik wrote: Hello All, Just checked clirr report one more time This time I took 1 error and perform investigation: "Method 'public java.util.Collection values()' has been added to an interface" org.apache.commons.collections4.BidiMap In fact I don't understand why this error was reported BidiMap extends java.util.Map Map has method "public java.util.Collection values()" in all versions: https://docs.oracle.com/javase/6/docs/api/java/util/Map.html https://docs.oracle.com/javase/7/docs/api/java/util/Map.html https://docs.oracle.com/javase/8/docs/api/java/util/Map.html Maybe its clirr issue? Might worth trying another tool: https://revapi.org/ [If you look into the log of "Commons RNG", there was a recent commit with the config to activate it (which I've removed afterwards since Clirr was not the cause of my problem there).] Would appreciate any help with this investigation Maybe totally unrelated but I've noticed that after deleting all "collections"-related maven caches, the build $ mvn clean site started by downloading _all_ older versions... Regards, Gilles On Mon, 31 Dec 2018 at 16:53, Gilles wrote: On Mon, 31 Dec 2018 07:41:40 +0700, Maxim Solodovnik wrote: > Hello Gilles, > > I already did analysis: [1], all errors are caused by previous > release > 4.3 doesn't introduce any new errors ... > > [1] https://markmail.org/message/l7ftxlvdk4yqxijt I had seen the post but it says: --- these errors are weird. Above classes has no changes comparing to 4.2 --- But IMHO it was not a conclusion: If the cause of the errors was identified, it could have been mentioned in the release notes and/or the [VOTE] email, in order to avoid further questioning. Is the cause the change of supported JDK? Regards, Gilles > > On Mon, 31 Dec 2018 at 07:26, Rob Tompkins > wrote: >> >> I’ll give it a look tonight or in the morning. >> >> -Rob >> >> > On Dec 30, 2018, at 12:25 AM, Maxim Solodovnik >> wrote: >> > >> > No votes after 3 days :( >> > Is there anything wrong with the RC? >> > >> >> On Thu, 27 Dec 2018 at 05:20, Bruno P. Kinoshita >> wrote: >> >> >> >> FWIW I had a similar experience, and realized I was doing `git >> fetch --all`, but it didn't bring the tags. `git fetch --tags` did the >> trick. After that I could `git checkout $tag-name` >> >> >> >> Cheers >> >> Bruno >> >> >> >> >> >> >> >> >> >> >> >> From: Gilles >> >> To: dev@commons.apache.org >> >> Sent: Thursday, 27 December 2018 9:26 AM >> >> Subject: Re: [VOTE][RC2] Commons collections 4.3 >> >> >> >> >> >> >> >>> On Wed, 26 Dec 2018 21:21:34 +0100, Gilles wrote: >> >>> Hi. >> >>> >> >>>> On Wed, 26 Dec 2018 20:41:59 +0700, Maxim Solodovnik wrote: >> >>>> This is a [VOTE] for releasing >> >>>> Apache Commons collections 4.3 >> >>>> >> >>>> Tag name: >> >>>>collections-4.3-RC2 (signature can be checked from git using >> >>>> 'git >> >>>> tag -v') >> >>> >> >>> $ git tag -v collections-4.3-RC2 >> >>> error: tag 'collections-4.3-RC2' not found. >> >>> >> >>> Although I see it in the link below... >> >>> What is going on? >> >> >> >> Issue vanished with a fresh "clone". >> >> [Sorry for the noise.] >> >> >> >> >> >>>> RC1 was cancelled due to some release steps were not done >> >>>> >> >>>> Tag URL: >> >>>> >> >>>> >> >>>> >> https://gitbox.apache.org/repos/asf?p=commons-collections.git;a=commit;h=77e37dbf238d26351edb29e95391e3df75095d01 >> >>>> >> >>>> Commit ID the tag points at: >> >>>>77e37dbf238d26351edb29e95391e3df75095d01 >> >>>> >> >>>> Site: >> >>>> >> >>>> >> >>>> >> https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC2/site/index.html >> >>> >> >>> The Clirr report is still a problem: >> >>> >> >>> >> >>> >> https://dist.apache.org/repos/dist/dev/commons/collections/4.3-RC2/site/clirr
Re: [VOTE][RC2] Commons collections 4.3
On Wed, 02 Jan 2019 12:38:23 +0100, Gilles wrote:
Hello.
On Wed, 2 Jan 2019 14:01:24 +0700, Maxim Solodovnik wrote:
Hello All,
Just checked clirr report one more time
This time I took 1 error and perform investigation:
"Method 'public java.util.Collection values()' has been added to an
interface" org.apache.commons.collections4.BidiMap
In fact I don't understand why this error was reported
BidiMap extends java.util.Map
Map has method "public java.util.Collection values()" in all
versions:
https://docs.oracle.com/javase/6/docs/api/java/util/Map.html
https://docs.oracle.com/javase/7/docs/api/java/util/Map.html
https://docs.oracle.com/javase/8/docs/api/java/util/Map.html
Maybe its clirr issue?
Might worth trying another tool:
https://revapi.org/
This is the config for the "" section:
---CUT---
org.revapi
revapi-maven-plugin
0.10.5
org.revapi
revapi-java
0.18.2
check
check
---CUT---
and for the "":
---CUT---
org.revapi
revapi-maven-plugin
0.10.5
report
report-aggregate
---CUT---
Gilles
[If you look into the log of "Commons RNG", there was a
recent commit with the config to activate it (which I've
removed afterwards since Clirr was not the cause of my
problem there).]
Would appreciate any help with this investigation
Maybe totally unrelated but I've noticed that after deleting
all "collections"-related maven caches, the build
$ mvn clean site
started by downloading _all_ older versions...
Regards,
Gilles
On Mon, 31 Dec 2018 at 16:53, Gilles
wrote:
On Mon, 31 Dec 2018 07:41:40 +0700, Maxim Solodovnik wrote:
> Hello Gilles,
>
> I already did analysis: [1], all errors are caused by previous
> release
> 4.3 doesn't introduce any new errors ...
>
> [1] https://markmail.org/message/l7ftxlvdk4yqxijt
I had seen the post but it says:
---
these errors are weird. Above classes has no changes comparing to
4.2
---
But IMHO it was not a conclusion: If the cause of the errors was
identified, it could have been mentioned in the release notes
and/or the [VOTE] email, in order to avoid further questioning.
Is the cause the change of supported JDK?
Regards,
Gilles
>
> On Mon, 31 Dec 2018 at 07:26, Rob Tompkins
> wrote:
>>
>> I’ll give it a look tonight or in the morning.
>>
>> -Rob
>>
>> > On Dec 30, 2018, at 12:25 AM, Maxim Solodovnik
>> wrote:
>> >
>> > No votes after 3 days :(
>> > Is there anything wrong with the RC?
>> >
>> >> On Thu, 27 Dec 2018 at 05:20, Bruno P. Kinoshita
>> wrote:
>> >>
>> >> FWIW I had a similar experience, and realized I was doing
`git
>> fetch --all`, but it didn't bring the tags. `git fetch --tags`
did the
>> trick. After that I could `git checkout $tag-name`
>> >>
>> >> Cheers
>> >> Bruno
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> From: Gilles
>> >> To: dev@commons.apache.org
>> >> Sent: Thursday, 27 December 2018 9:26 AM
>> >> Subject: Re: [VOTE][RC2] Commons collections 4.3
>> >>
>> >>
>> >>
>> >>> On Wed, 26 Dec 2018 21:21:34 +0100, Gilles wrote:
>> >>> Hi.
>> >>>
>> >>>> On Wed, 26 Dec 2018 20:41:59 +0700, Maxim Solodovnik wrote:
>> >>>> This is a [VOTE] for releasing
>> >>>> Apache Commons collections 4.3
>> >>>>
>> >>>> Tag name:
>> >>>>collections-4.3-RC2 (signature can be checked from git
using
>> >>>> 'git
>> >>>> tag -v')
>> >>>
>> >>> $ git tag -v collections-4.3-RC2
>> >>> error: tag 'collections-4.3-RC2' not found.
>> >>>
>> >>> Although I see it in the link below...
>> >>> What is going on?
>> >>
>> >> Issue vanished with a fresh "clone".
>> >> [Sorry for the noise.]
>> >>
>> >>
>> >>>> RC1 was cancelled due to some release steps were not done
>> >>>>
>> >>>> Tag URL:
>> >>>>
>> >>>>
>> >>>>
>>
https://gitbox.apache.org/repos/asf?p=commons-collections.git;a=commit;h=77e37dbf2
Re: [VOTE][RC2] Commons collections 4.3
hi. On Thu, 3 Jan 2019 22:04:24 +0530, Amey Jadiye wrote: Hello Maxim / All I put little more efforts to find out the possible cause of the error. In the clirr code, I found the reason for this error and same is documented in clirr documentation [1]. A method declaration has been added to the specified interface. This is always reported as a binary-compatibility error, but in practice, the changed class might be used successfully with code compiled against the old interface depending upon usage patterns. Old code which invokes methods upon code compiled against the new (expanded) interface will continue to work without issues. And old code which implements the old version of the interface will also continue to work correctly as long as no code attempts to invoke any of the newly-added methods against that instance. But the code which (validly) invokes one of the new methods in the interface against an object which implements only the old version of the interface will cause an AbstractMethodError to be thrown at the time the method invocation is attempted. IIUC, new code that calls the new methods on [Collections] classes will crash. Does not look good. On the other hand, Maxim wrote earlier that a method reported by Clirr as "new" (cf. below) was in fact present since Java 6... Are we then sure that it's a Clirr bug? If so, why did you not vote "+1" (on the condition that the false positive is mentioned in the release notes)? We could also make some definite progress with an actual code example that calls the incriminated methods, compiled against the current version of the library and then run against the current RC, and see whether it crashes. Alternatively, we could instate "revapi" in the POM (and disable Clirr); and if the report is clean, trust that (though "revapi" is still beta). Opinions? Gilles In 4.2 and 4.3 looks like we have upgraded the java version[2] where for example for Map interface might have added a few more methods causing these errors. For this release, I am voting 0 (Non-Binding) as there is unharmed mess around the clirr. rest of the things are OK with this release, I would encourage to have revapi replacing clirr. [1] http://clirr.sourceforge.net/clirr-core/exegesis.html [2] https://github.com/apache/commons-collections/commit/482762a13f739631f94d03642b0a55a9b7214c44 Regards, Amey On Thu, Jan 3, 2019 at 11:53 AM Amey Jadiye wrote: I spared little time on finding issue however didn't found it in clirr(may be hidden somewhere), today will check if clirr maven plugin have any issues. also I saw that few other apache commons modules having same issue and are released. I also gave try on revapi with commons collection4 4.3RC2. revapi:check was clean unlike clirr, looks promising to replace clirr. Regards, Amey On Wed, 2 Jan 2019, 12:31 pm Maxim Solodovnik wrote: Hello All, Just checked clirr report one more time This time I took 1 error and perform investigation: "Method 'public java.util.Collection values()' has been added to an interface" org.apache.commons.collections4.BidiMap In fact I don't understand why this error was reported BidiMap extends java.util.Map Map has method "public java.util.Collection values()" in all versions: https://docs.oracle.com/javase/6/docs/api/java/util/Map.html https://docs.oracle.com/javase/7/docs/api/java/util/Map.html https://docs.oracle.com/javase/8/docs/api/java/util/Map.html Maybe its clirr issue? Would appreciate any help with this investigation On Mon, 31 Dec 2018 at 16:53, Gilles wrote: > > On Mon, 31 Dec 2018 07:41:40 +0700, Maxim Solodovnik wrote: > > Hello Gilles, > > > > I already did analysis: [1], all errors are caused by previous > > release > > 4.3 doesn't introduce any new errors ... > > > > [1] https://markmail.org/message/l7ftxlvdk4yqxijt > > I had seen the post but it says: > --- > these errors are weird. Above classes has no changes comparing to 4.2 > --- > > But IMHO it was not a conclusion: If the cause of the errors was > identified, it could have been mentioned in the release notes > and/or the [VOTE] email, in order to avoid further questioning. > > Is the cause the change of supported JDK? > > Regards, > Gilles > > > > > On Mon, 31 Dec 2018 at 07:26, Rob Tompkins > > wrote: > >> > >> I’ll give it a look tonight or in the morning. > >> > >> -Rob > >> > >> > On Dec 30, 2018, at 12:25 AM, Maxim Solodovnik > >> wrote: > >> > > >> > No votes after 3 days :( > >> > Is there anything wrong with the RC? > >> > > >> >> On Thu, 27 Dec 2018 at 05:20, Bruno P. Kinoshita > >> wrote: > >> >> > >> >
Re: [Math] Git question (Was: [VOTE][RC3] Release ...)
On Wed, 24 Dec 2014 03:56:10 +0100, Bernd Eckenfels wrote: Am Wed, 24 Dec 2014 03:36:42 +0100 schrieb Gilles : On Tue, 23 Dec 2014 14:02:40 +0100, luc wrote: Is there a way to check that the source code referred to above was the one used to create the JAR of the ".class" files. [Out of curiosity, not suspicion, of course...] You can try to build it yourself and compare the binaries. But this requires the same compiler version on the same OS - and it might still create some differences if things like hostnames or timestamps are involved. (it should be however possible to inspect differences and see if they fall in this category). I was wondering if there is a way that the JAR could include some signature/checksum of the source code compiled to produce it, something that would not be different even if checked on different hosts with different compilers, etc. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Git question (Was: [VOTE][RC3] Release ...)
On Wed, 24 Dec 2014 09:31:46 +0100, Luc Maisonobe wrote: Le 24/12/2014 03:36, Gilles a écrit : On Tue, 23 Dec 2014 14:02:40 +0100, luc wrote: This is a [VOTE] for releasing Apache Commons Math 3.4 from release candidate 3. Tag name: MATH_3_4_RC3 (signature can be checked from git using 'git tag -v') Tag URL: <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=befd8ebd96b8ef5a06b59dccb22bd55064e31c34> Is there a way to check that the source code referred to above was the one used to create the JAR of the ".class" files. [Out of curiosity, not suspicion, of course...] Yes, you can look at the end of the META-INF/MANIFEST.MS file embedded in the jar. The second-to-last entry is called Implementation-Build. It is automatically created by maven-jgit-buildnumber-plugin and contains the SHA1 identifier of the last commit used for the build. Here, is is befd8ebd96b8ef5a06b59dccb22bd55064e31c34, so we can check it really corresponds to the expected status of the git repository. Can this be considered "secure", i.e. can't this entry in the MANIFEST file be modified to be the checksum of the repository but with the .class files being substitued with those coming from another compilation? Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][RC3] Release Commons Math 3.4
On Tue, 23 Dec 2014 14:02:40 +0100, luc wrote: This is a [VOTE] for releasing Apache Commons Math 3.4 from release candidate 3. Tag name: MATH_3_4_RC3 (signature can be checked from git using 'git tag -v') Tag URL: <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=befd8ebd96b8ef5a06b59dccb22bd55064e31c34> Commit ID the tag points at: befd8ebd96b8ef5a06b59dccb22bd55064e31c34 Site: <https://people.apache.org/~luc/commons-math-3.4-RC3-site> Distribution files: <https://dist.apache.org/repos/dist/dev/commons/math/> Distribution files hashes (SHA1): 79787d6a6861e3093fbb0a8df0baa177040cc4fa commons-math3-3.4-bin.tar.gz 1dc1a7c031ce7df1a3ef9db11afe85ddb4f30c36 commons-math3-3.4-bin.zip 2ed3ee2122cd95b2c71f0df97abb1cbb12c8dad7 commons-math3-3.4-src.tar.gz 32cc6f6f5a4a56fffa39027f3f9a6519b554f7db commons-math3-3.4-src.zip KEYS file to check signatures: <http://www.apache.org/dist/commons/KEYS> Maven artifacts: <https://repository.apache.org/content/repositories/orgapachecommons-1069/org/apache/commons/commons-math3/3.4/> [X] +1 Release it. [ ] +0 Go ahead; I don't care. [ ] -0 There are a few minor glitches: ... [ ] -1 No, do not release it because ... This vote will close in 72 hours, at 2014-12-26T13:05;00Z (this is UTC time). Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Git question (Was: [VOTE][RC3] Release ...)
On Wed, 24 Dec 2014 15:52:12 +0100, Luc Maisonobe wrote: Le 24/12/2014 15:04, Gilles a écrit : On Wed, 24 Dec 2014 09:31:46 +0100, Luc Maisonobe wrote: Le 24/12/2014 03:36, Gilles a écrit : On Tue, 23 Dec 2014 14:02:40 +0100, luc wrote: This is a [VOTE] for releasing Apache Commons Math 3.4 from release candidate 3. Tag name: MATH_3_4_RC3 (signature can be checked from git using 'git tag -v') Tag URL: <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=befd8ebd96b8ef5a06b59dccb22bd55064e31c34> Is there a way to check that the source code referred to above was the one used to create the JAR of the ".class" files. [Out of curiosity, not suspicion, of course...] Yes, you can look at the end of the META-INF/MANIFEST.MS file embedded in the jar. The second-to-last entry is called Implementation-Build. It is automatically created by maven-jgit-buildnumber-plugin and contains the SHA1 identifier of the last commit used for the build. Here, is is befd8ebd96b8ef5a06b59dccb22bd55064e31c34, so we can check it really corresponds to the expected status of the git repository. Can this be considered "secure", i.e. can't this entry in the MANIFEST file be modified to be the checksum of the repository but with the .class files being substitued with those coming from another compilation? Modifying anything in the jar (either this entry within the manifest or any class) will modify the jar signature. So as long as people do check the global MD5, SHA1 or gpg signature we provide with our build, they are safe to assume the artifacts are Apache artifacts. This is not different from how releases are done with subversion as the source code control system, or even in C or C++ as the language. At one time, the release manager does perform a compilation and the fellow reviewers check the result. There is no fullproof process here, as always when security is involved. Even using an automated build and automatic signing on an Apache server would involve trust (i.e. one should assume that the server has not been tampered with, that the build process really does what it is expected to do, that the artifacts put to review are really the one created by the automatic process ...). Another point is that what we officially release is the source, which can be reviewed by external users. The binary parts are merely a convenience. That's an interesting point to come back to since it looks like the most time-consuming part of a release is not related to the sources! Isn't it conceivable that a release could just be a commit identifier and a checksum of the repository? If the binaries are a just a convenience, why put so much effort in it? As a convenience, the artefacts could be produced after the release, accompanied with all the "caveat" notes which you mentioned. That would certainly increase the release rate. Best regards, Gilles We do our best to ensure they are genuine and we do apply signatures to them too, but people who do not trust them should use the source, audit them, and then compile them on their own (assuming they also trust their compiler, their OS ...). best regards, Luc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RESULT][VOTE][RC3] Release Commons Math 3.4
On Fri, 26 Dec 2014 18:28:11 +0100, Luc Maisonobe wrote: Le 23/12/2014 14:02, luc a écrit : This is a [VOTE] for releasing Apache Commons Math 3.4 from release candidate 3. Tag name: MATH_3_4_RC3 (signature can be checked from git using 'git tag -v') Tag URL: <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=befd8ebd96b8ef5a06b59dccb22bd55064e31c34> Commit ID the tag points at: befd8ebd96b8ef5a06b59dccb22bd55064e31c34 Site: <https://people.apache.org/~luc/commons-math-3.4-RC3-site> Distribution files: <https://dist.apache.org/repos/dist/dev/commons/math/> Distribution files hashes (SHA1): 79787d6a6861e3093fbb0a8df0baa177040cc4fa commons-math3-3.4-bin.tar.gz 1dc1a7c031ce7df1a3ef9db11afe85ddb4f30c36 commons-math3-3.4-bin.zip 2ed3ee2122cd95b2c71f0df97abb1cbb12c8dad7 commons-math3-3.4-src.tar.gz 32cc6f6f5a4a56fffa39027f3f9a6519b554f7db commons-math3-3.4-src.zip KEYS file to check signatures: <http://www.apache.org/dist/commons/KEYS> Maven artifacts: <https://repository.apache.org/content/repositories/orgapachecommons-1069/org/apache/commons/commons-math3/3.4/> [ ] +1 Release it. [ ] +0 Go ahead; I don't care. [ ] -0 There are a few minor glitches: ... [ ] -1 No, do not release it because ... This vote will close in 72 hours, at 2014-12-26T13:05;00Z (this is UTC time). This vote has passed with the following +1 votes: Luc Maisonobe(binding) Thomas Neidhart (binding) Phil Steitz (binding) Gilles Sadowski (binding) No other votes were cast. Hank Grabowski voted +1. Best regards, Gilles I will proceed with the release. Thanks to those who voted and reviewed this and the previous candidates. best regards, Luc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Math] What's in a release (Was: [Math] Git question (Was: [VOTE][RC3] Release ...))
On Sat, 27 Dec 2014 17:48:05 +, sebb wrote: On 24 December 2014 at 15:11, Gilles wrote: On Wed, 24 Dec 2014 15:52:12 +0100, Luc Maisonobe wrote: Le 24/12/2014 15:04, Gilles a écrit : On Wed, 24 Dec 2014 09:31:46 +0100, Luc Maisonobe wrote: Le 24/12/2014 03:36, Gilles a écrit : On Tue, 23 Dec 2014 14:02:40 +0100, luc wrote: This is a [VOTE] for releasing Apache Commons Math 3.4 from release candidate 3. Tag name: MATH_3_4_RC3 (signature can be checked from git using 'git tag -v') Tag URL: <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=befd8ebd96b8ef5a06b59dccb22bd55064e31c34> Is there a way to check that the source code referred to above was the one used to create the JAR of the ".class" files. [Out of curiosity, not suspicion, of course...] Yes, you can look at the end of the META-INF/MANIFEST.MS file embedded in the jar. The second-to-last entry is called Implementation-Build. It is automatically created by maven-jgit-buildnumber-plugin and contains the SHA1 identifier of the last commit used for the build. Here, is is befd8ebd96b8ef5a06b59dccb22bd55064e31c34, so we can check it really corresponds to the expected status of the git repository. Can this be considered "secure", i.e. can't this entry in the MANIFEST file be modified to be the checksum of the repository but with the .class files being substitued with those coming from another compilation? Modifying anything in the jar (either this entry within the manifest or any class) will modify the jar signature. So as long as people do check the global MD5, SHA1 or gpg signature we provide with our build, they are safe to assume the artifacts are Apache artifacts. This is not different from how releases are done with subversion as the source code control system, or even in C or C++ as the language. At one time, the release manager does perform a compilation and the fellow reviewers check the result. There is no fullproof process here, as always when security is involved. Even using an automated build and automatic signing on an Apache server would involve trust (i.e. one should assume that the server has not been tampered with, that the build process really does what it is expected to do, that the artifacts put to review are really the one created by the automatic process ...). Another point is that what we officially release is the source, which can be reviewed by external users. The binary parts are merely a convenience. That's an interesting point to come back to since it looks like the most time-consuming part of a release is not related to the sources! Isn't it conceivable that a release could just be a commit identifier and a checksum of the repository? If the binaries are a just a convenience, why put so much effort in it? As a convenience, the artefacts could be produced after the release, accompanied with all the "caveat" notes which you mentioned. That would certainly increase the release rate. Binary releases still need to be reviewed to ensure that the correct N & L files are present, and that the archives don't contain material with disallowed licenses. It's not unknown for automated build processes to include files that should not be present. I fail to see the difference of principle between the "release" context and, say, the daily snapshot context. What I mean is that there seem to be a contradiction between saying that a "release" is only about _source_ and the obligation to check _binaries_. It can occur that disallowed material is, at some point in time, part of the repository and/or the snapshot binaries. However, what is forbidden is... forbidden, at all times. If it is indeed a problem to distribute forbidden material, shouldn't this be corrected in the repository? [That's indeed what you did with the blocking of the release.] Then again, once the repository is "clean", it can be tagged and that tagged _source_ is the release. Non-compliant binaries would thus only be the result of a "mistake" (if the build system is flawed, it's another problem, unrelated to the released contents, which is _source_) to be corrected per se. My proposition is that it's an independent step: once the build system is adjusted to the expectations, "correct" binaries can be generated from the same tagged release. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCEMENT] Apache Commons Math 3.4 Released
Hello Luc. On Sun, 28 Dec 2014 17:06:05 +0100, Luc Maisonobe wrote: The Apache Commons Team is pleased to announce the availability of Apache Commons Math 3.4. Thank you for all the work (release + howto). Happy New Year, Gilles [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] What's in a release
Hi. On Sun, 28 Dec 2014 09:43:34 +0100, Luc Maisonobe wrote: Le 28/12/2014 00:22, sebb a écrit : On 27 December 2014 at 22:19, Gilles wrote: On Sat, 27 Dec 2014 17:48:05 +, sebb wrote: On 24 December 2014 at 15:11, Gilles wrote: On Wed, 24 Dec 2014 15:52:12 +0100, Luc Maisonobe wrote: Le 24/12/2014 15:04, Gilles a écrit : On Wed, 24 Dec 2014 09:31:46 +0100, Luc Maisonobe wrote: Le 24/12/2014 03:36, Gilles a écrit : On Tue, 23 Dec 2014 14:02:40 +0100, luc wrote: This is a [VOTE] for releasing Apache Commons Math 3.4 from release candidate 3. Tag name: MATH_3_4_RC3 (signature can be checked from git using 'git tag -v') Tag URL: <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=befd8ebd96b8ef5a06b59dccb22bd55064e31c34> Is there a way to check that the source code referred to above was the one used to create the JAR of the ".class" files. [Out of curiosity, not suspicion, of course...] Yes, you can look at the end of the META-INF/MANIFEST.MS file embedded in the jar. The second-to-last entry is called Implementation-Build. It is automatically created by maven-jgit-buildnumber-plugin and contains the SHA1 identifier of the last commit used for the build. Here, is is befd8ebd96b8ef5a06b59dccb22bd55064e31c34, so we can check it really corresponds to the expected status of the git repository. Can this be considered "secure", i.e. can't this entry in the MANIFEST file be modified to be the checksum of the repository but with the .class files being substitued with those coming from another compilation? Modifying anything in the jar (either this entry within the manifest or any class) will modify the jar signature. So as long as people do check the global MD5, SHA1 or gpg signature we provide with our build, they are safe to assume the artifacts are Apache artifacts. This is not different from how releases are done with subversion as the source code control system, or even in C or C++ as the language. At one time, the release manager does perform a compilation and the fellow reviewers check the result. There is no fullproof process here, as always when security is involved. Even using an automated build and automatic signing on an Apache server would involve trust (i.e. one should assume that the server has not been tampered with, that the build process really does what it is expected to do, that the artifacts put to review are really the one created by the automatic process ...). Another point is that what we officially release is the source, which can be reviewed by external users. The binary parts are merely a convenience. That's an interesting point to come back to since it looks like the most time-consuming part of a release is not related to the sources! Isn't it conceivable that a release could just be a commit identifier and a checksum of the repository? If the binaries are a just a convenience, why put so much effort in it? As a convenience, the artefacts could be produced after the release, accompanied with all the "caveat" notes which you mentioned. That would certainly increase the release rate. Binary releases still need to be reviewed to ensure that the correct N & L files are present, and that the archives don't contain material with disallowed licenses. It's not unknown for automated build processes to include files that should not be present. I fail to see the difference of principle between the "release" context and, say, the daily snapshot context. Snapshots are not (should not) be promoted to the general public as releases of the ASF. What I mean is that there seem to be a contradiction between saying that a "release" is only about _source_ and the obligation to check _binaries_. There is no contradiction here. The ASF releases source, they are required in a release. Binaries are optional. That does not mean that the ASF mirror system can be used to distribute arbitrary binaries. It can occur that disallowed material is, at some point in time, part of the repository and/or the snapshot binaries. However, what is forbidden is... forbidden, at all times. As with most things, this is not a strict dichotomy. If it is indeed a problem to distribute forbidden material, shouldn't this be corrected in the repository? [That's indeed what you did with the blocking of the release.] If the repo is discovered to contain disallowed material, it needs to be removed. Then again, once the repository is "clean", it can be tagged and that tagged _source_ is the release. Not quite. A release is a source archive that is voted on and distributed via the ASF mirror system. The contents must agree with the source tag, but the source tag is not the release. Non-compliant binaries would thus only be the result of a "mistake" (if
Re: [Math] What's in a release
On Sun, 28 Dec 2014 20:21:32 -0700, Phil Steitz wrote: On 12/28/14 11:46 AM, Gilles wrote: Hi. On Sun, 28 Dec 2014 09:43:34 +0100, Luc Maisonobe wrote: Le 28/12/2014 00:22, sebb a écrit : On 27 December 2014 at 22:19, Gilles wrote: On Sat, 27 Dec 2014 17:48:05 +, sebb wrote: On 24 December 2014 at 15:11, Gilles wrote: On Wed, 24 Dec 2014 15:52:12 +0100, Luc Maisonobe wrote: Le 24/12/2014 15:04, Gilles a écrit : On Wed, 24 Dec 2014 09:31:46 +0100, Luc Maisonobe wrote: Le 24/12/2014 03:36, Gilles a écrit : On Tue, 23 Dec 2014 14:02:40 +0100, luc wrote: This is a [VOTE] for releasing Apache Commons Math 3.4 from release candidate 3. Tag name: MATH_3_4_RC3 (signature can be checked from git using 'git tag -v') Tag URL: <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=befd8ebd96b8ef5a06b59dccb22bd55064e31c34> Is there a way to check that the source code referred to above was the one used to create the JAR of the ".class" files. [Out of curiosity, not suspicion, of course...] Yes, you can look at the end of the META-INF/MANIFEST.MS file embedded in the jar. The second-to-last entry is called Implementation-Build. It is automatically created by maven-jgit-buildnumber-plugin and contains the SHA1 identifier of the last commit used for the build. Here, is is befd8ebd96b8ef5a06b59dccb22bd55064e31c34, so we can check it really corresponds to the expected status of the git repository. Can this be considered "secure", i.e. can't this entry in the MANIFEST file be modified to be the checksum of the repository but with the .class files being substitued with those coming from another compilation? Modifying anything in the jar (either this entry within the manifest or any class) will modify the jar signature. So as long as people do check the global MD5, SHA1 or gpg signature we provide with our build, they are safe to assume the artifacts are Apache artifacts. This is not different from how releases are done with subversion as the source code control system, or even in C or C++ as the language. At one time, the release manager does perform a compilation and the fellow reviewers check the result. There is no fullproof process here, as always when security is involved. Even using an automated build and automatic signing on an Apache server would involve trust (i.e. one should assume that the server has not been tampered with, that the build process really does what it is expected to do, that the artifacts put to review are really the one created by the automatic process ...). Another point is that what we officially release is the source, which can be reviewed by external users. The binary parts are merely a convenience. That's an interesting point to come back to since it looks like the most time-consuming part of a release is not related to the sources! Isn't it conceivable that a release could just be a commit identifier and a checksum of the repository? If the binaries are a just a convenience, why put so much effort in it? As a convenience, the artefacts could be produced after the release, accompanied with all the "caveat" notes which you mentioned. That would certainly increase the release rate. Binary releases still need to be reviewed to ensure that the correct N & L files are present, and that the archives don't contain material with disallowed licenses. It's not unknown for automated build processes to include files that should not be present. I fail to see the difference of principle between the "release" context and, say, the daily snapshot context. Snapshots are not (should not) be promoted to the general public as releases of the ASF. What I mean is that there seem to be a contradiction between saying that a "release" is only about _source_ and the obligation to check _binaries_. There is no contradiction here. The ASF releases source, they are required in a release. Binaries are optional. That does not mean that the ASF mirror system can be used to distribute arbitrary binaries. It can occur that disallowed material is, at some point in time, part of the repository and/or the snapshot binaries. However, what is forbidden is... forbidden, at all times. As with most things, this is not a strict dichotomy. If it is indeed a problem to distribute forbidden material, shouldn't this be corrected in the repository? [That's indeed what you did with the blocking of the release.] If the repo is discovered to contain disallowed material, it needs to be removed. Then again, once the repository is "clean", it can be tagged and that tagged _source_ is the release. Not quite. A release is a source archive that is voted on and distributed via the ASF mirror system. The contents must agree with the source tag, but the source tag is not the release. Non-compliant binaries would thus only be t
Re: [Math] What's in a release
On Mon, 29 Dec 2014 10:54:59 +, sebb wrote: On 29 December 2014 at 10:36, Gilles wrote: On Sun, 28 Dec 2014 20:21:32 -0700, Phil Steitz wrote: On 12/28/14 11:46 AM, Gilles wrote: Hi. On Sun, 28 Dec 2014 09:43:34 +0100, Luc Maisonobe wrote: Le 28/12/2014 00:22, sebb a écrit : On 27 December 2014 at 22:19, Gilles wrote: On Sat, 27 Dec 2014 17:48:05 +, sebb wrote: On 24 December 2014 at 15:11, Gilles wrote: On Wed, 24 Dec 2014 15:52:12 +0100, Luc Maisonobe wrote: Le 24/12/2014 15:04, Gilles a écrit : On Wed, 24 Dec 2014 09:31:46 +0100, Luc Maisonobe wrote: Le 24/12/2014 03:36, Gilles a écrit : On Tue, 23 Dec 2014 14:02:40 +0100, luc wrote: This is a [VOTE] for releasing Apache Commons Math 3.4 from release candidate 3. Tag name: MATH_3_4_RC3 (signature can be checked from git using 'git tag -v') Tag URL: <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=befd8ebd96b8ef5a06b59dccb22bd55064e31c34> Is there a way to check that the source code referred to above was the one used to create the JAR of the ".class" files. [Out of curiosity, not suspicion, of course...] Yes, you can look at the end of the META-INF/MANIFEST.MS file embedded in the jar. The second-to-last entry is called Implementation-Build. It is automatically created by maven-jgit-buildnumber-plugin and contains the SHA1 identifier of the last commit used for the build. Here, is is befd8ebd96b8ef5a06b59dccb22bd55064e31c34, so we can check it really corresponds to the expected status of the git repository. Can this be considered "secure", i.e. can't this entry in the MANIFEST file be modified to be the checksum of the repository but with the .class files being substitued with those coming from another compilation? Modifying anything in the jar (either this entry within the manifest or any class) will modify the jar signature. So as long as people do check the global MD5, SHA1 or gpg signature we provide with our build, they are safe to assume the artifacts are Apache artifacts. This is not different from how releases are done with subversion as the source code control system, or even in C or C++ as the language. At one time, the release manager does perform a compilation and the fellow reviewers check the result. There is no fullproof process here, as always when security is involved. Even using an automated build and automatic signing on an Apache server would involve trust (i.e. one should assume that the server has not been tampered with, that the build process really does what it is expected to do, that the artifacts put to review are really the one created by the automatic process ...). Another point is that what we officially release is the source, which can be reviewed by external users. The binary parts are merely a convenience. That's an interesting point to come back to since it looks like the most time-consuming part of a release is not related to the sources! Isn't it conceivable that a release could just be a commit identifier and a checksum of the repository? If the binaries are a just a convenience, why put so much effort in it? As a convenience, the artefacts could be produced after the release, accompanied with all the "caveat" notes which you mentioned. That would certainly increase the release rate. Binary releases still need to be reviewed to ensure that the correct N & L files are present, and that the archives don't contain material with disallowed licenses. It's not unknown for automated build processes to include files that should not be present. I fail to see the difference of principle between the "release" context and, say, the daily snapshot context. Snapshots are not (should not) be promoted to the general public as releases of the ASF. What I mean is that there seem to be a contradiction between saying that a "release" is only about _source_ and the obligation to check _binaries_. There is no contradiction here. The ASF releases source, they are required in a release. Binaries are optional. That does not mean that the ASF mirror system can be used to distribute arbitrary binaries. It can occur that disallowed material is, at some point in time, part of the repository and/or the snapshot binaries. However, what is forbidden is... forbidden, at all times. As with most things, this is not a strict dichotomy. If it is indeed a problem to distribute forbidden material, shouldn't this be corrected in the repository? [That's indeed what you did with the blocking of the release.] If the repo is discovered to contain disallowed material, it needs to be removed. Then again, once the repository is "clean", it can be tagged and that tagged _source_ is the release. Not quite. A release is a source archive that is voted on and distributed via the ASF mirror system. The conte
Re: [Math] What's in a release
On Mon, 29 Dec 2014 16:21:05 +0100, Thomas Neidhart wrote: On 12/29/2014 04:21 AM, Phil Steitz wrote: On 12/28/14 11:46 AM, Gilles wrote: Hi. On Sun, 28 Dec 2014 09:43:34 +0100, Luc Maisonobe wrote: Le 28/12/2014 00:22, sebb a écrit : On 27 December 2014 at 22:19, Gilles wrote: On Sat, 27 Dec 2014 17:48:05 +, sebb wrote: On 24 December 2014 at 15:11, Gilles wrote: On Wed, 24 Dec 2014 15:52:12 +0100, Luc Maisonobe wrote: Le 24/12/2014 15:04, Gilles a écrit : On Wed, 24 Dec 2014 09:31:46 +0100, Luc Maisonobe wrote: Le 24/12/2014 03:36, Gilles a écrit : On Tue, 23 Dec 2014 14:02:40 +0100, luc wrote: This is a [VOTE] for releasing Apache Commons Math 3.4 from release candidate 3. Tag name: MATH_3_4_RC3 (signature can be checked from git using 'git tag -v') Tag URL: <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=befd8ebd96b8ef5a06b59dccb22bd55064e31c34> Is there a way to check that the source code referred to above was the one used to create the JAR of the ".class" files. [Out of curiosity, not suspicion, of course...] Yes, you can look at the end of the META-INF/MANIFEST.MS file embedded in the jar. The second-to-last entry is called Implementation-Build. It is automatically created by maven-jgit-buildnumber-plugin and contains the SHA1 identifier of the last commit used for the build. Here, is is befd8ebd96b8ef5a06b59dccb22bd55064e31c34, so we can check it really corresponds to the expected status of the git repository. Can this be considered "secure", i.e. can't this entry in the MANIFEST file be modified to be the checksum of the repository but with the .class files being substitued with those coming from another compilation? Modifying anything in the jar (either this entry within the manifest or any class) will modify the jar signature. So as long as people do check the global MD5, SHA1 or gpg signature we provide with our build, they are safe to assume the artifacts are Apache artifacts. This is not different from how releases are done with subversion as the source code control system, or even in C or C++ as the language. At one time, the release manager does perform a compilation and the fellow reviewers check the result. There is no fullproof process here, as always when security is involved. Even using an automated build and automatic signing on an Apache server would involve trust (i.e. one should assume that the server has not been tampered with, that the build process really does what it is expected to do, that the artifacts put to review are really the one created by the automatic process ...). Another point is that what we officially release is the source, which can be reviewed by external users. The binary parts are merely a convenience. That's an interesting point to come back to since it looks like the most time-consuming part of a release is not related to the sources! Isn't it conceivable that a release could just be a commit identifier and a checksum of the repository? If the binaries are a just a convenience, why put so much effort in it? As a convenience, the artefacts could be produced after the release, accompanied with all the "caveat" notes which you mentioned. That would certainly increase the release rate. Binary releases still need to be reviewed to ensure that the correct N & L files are present, and that the archives don't contain material with disallowed licenses. It's not unknown for automated build processes to include files that should not be present. I fail to see the difference of principle between the "release" context and, say, the daily snapshot context. Snapshots are not (should not) be promoted to the general public as releases of the ASF. What I mean is that there seem to be a contradiction between saying that a "release" is only about _source_ and the obligation to check _binaries_. There is no contradiction here. The ASF releases source, they are required in a release. Binaries are optional. That does not mean that the ASF mirror system can be used to distribute arbitrary binaries. It can occur that disallowed material is, at some point in time, part of the repository and/or the snapshot binaries. However, what is forbidden is... forbidden, at all times. As with most things, this is not a strict dichotomy. If it is indeed a problem to distribute forbidden material, shouldn't this be corrected in the repository? [That's indeed what you did with the blocking of the release.] If the repo is discovered to contain disallowed material, it needs to be removed. Then again, once the repository is "clean", it can be tagged and that tagged _source_ is the release. Not quite. A release is a source archive that is voted on and distributed via the ASF mirror system. The contents must agree with the source tag, but the source tag is not the
Re: [Math] What's in a release
On Tue, 30 Dec 2014 02:09:42 +0100, Bernd Eckenfels wrote: That thread gets deep. :) I just wanted to comment on "releasing only source is faster because of less checks". I disagree with that, most release delay/time is due to preparation work. Failed (binary) checks are typically for a reason which would also be present in the source (especially the POM), so it does not really reduce the number of rework. RM is a streamlined procedure: so, if you do (say) 10 steps rather than 15, it will objectively take less time, and this is compounded by the additional tests which should (ideally) be performed by the reviewers. [Thus delaying the release.] (At least not in most cases, so two votes will actually make us more work not less). The additional work exactly amounts to sending _one_ additional mail. Then, as I noted, * some releases will be done as before (same work) * some releases will be "source only" (less work) * some releases will be two-steps, possibly performed by two different people (i.e. less work for each RM) Of course, each release means some work has to be done; then IIUC your point, the fewer releases the better. :-} Regards, Gilles Gruss Bernd Am Tue, 30 Dec 2014 02:05:29 +0100 schrieb Gilles : On Mon, 29 Dec 2014 10:54:59 +, sebb wrote: > On 29 December 2014 at 10:36, Gilles > wrote: >> On Sun, 28 Dec 2014 20:21:32 -0700, Phil Steitz wrote: >>> >>> On 12/28/14 11:46 AM, Gilles wrote: >>>> >>>> Hi. >>>> >>>> On Sun, 28 Dec 2014 09:43:34 +0100, Luc Maisonobe wrote: >>>>> >>>>> Le 28/12/2014 00:22, sebb a écrit : >>>>>> >>>>>> On 27 December 2014 at 22:19, Gilles >>>>>> wrote: >>>>>>> >>>>>>> On Sat, 27 Dec 2014 17:48:05 +, sebb wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 24 December 2014 at 15:11, Gilles >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, 24 Dec 2014 15:52:12 +0100, Luc Maisonobe wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le 24/12/2014 15:04, Gilles a écrit : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, 24 Dec 2014 09:31:46 +0100, Luc Maisonobe wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Le 24/12/2014 03:36, Gilles a écrit : >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, 23 Dec 2014 14:02:40 +0100, luc wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is a [VOTE] for releasing Apache Commons Math 3.4 >>>>>>>>>>>>>> from release >>>>>>>>>>>>>> candidate 3. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tag name: >>>>>>>>>>>>>> MATH_3_4_RC3 (signature can be checked from git using >>>>>>>>>>>>>> 'git tag >>>>>>>>>>>>>> -v') >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tag URL: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=befd8ebd96b8ef5a06b59dccb22bd55064e31c34> >>>>>>>>>>>>
Re: [Math] What's in a release
On Tue, 30 Dec 2014 02:36:24 +0100, Bernd Eckenfels wrote: Hello, Am Tue, 30 Dec 2014 02:29:38 +0100 schrieb Gilles : On Tue, 30 Dec 2014 02:09:42 +0100, Bernd Eckenfels wrote: > That thread gets deep. :) > > I just wanted to comment on "releasing only > source is faster because of less checks". I disagree with that, most > release delay/time is due to preparation work. Failed (binary) > checks are typically for a reason which would also be present in > the source (especially the POM), so it does not really reduce the > number of rework. RM is a streamlined procedure: so, if you do (say) 10 steps rather than 15, it will objectively take less time, and this is compounded by the additional tests which should (ideally) be performed by the reviewers. [Thus delaying the release.] The problem is not the small additional time for the last 5 steps but the large time for redoing all steps (on veto). That's not my experience. [I particularly hated to have to delete manually some files inside Nexus: Wrong click, and up for another round... :-/] Moreover, most of the initial tasks are shared between the active contributors (committing pending patches, cleaing up code, evaluating pending issues). And the collective effort is hopefully triggered by the perspective of the release. > (At least not in most cases, so two votes will actually make us > more work not less). The additional work exactly amounts to sending _one_ additional mail. The actual work is not the vote mail but the people doing the preparation and the review. Yes, and that is _exactly_ the same work because the total work for the two steps combined is the sum of each of the steps! ;-) Then, as I noted, * some releases will be done as before (same work) * some releases will be "source only" (less work) Not much, you still have to check if the source actually works and can be build, produces sane archives and so on. Well, no. Source-only is source-only; sane compilation is always implicitly checked by the "test" target, which is the minimum required to ensure that the source is OK. * some releases will be two-steps, possibly performed by two different people (i.e. less work for each RM) And more work in sum, not only for the RMs but also the reviewers. (and the users which want to use the source release with maven like anybody there days) I'd expect that most source would come with "convenience" binaries. The main point is that some "official" release can be provided more quickly if the circumstance would require it (e.g. urgent bug fix or new feature for a user who would be satisfied with a source release). But I dont mind, if a project wants to do a source release only, thats fine with me, I just don't see the advantage. In one word: Flexibility. Gilles Gruss Bernd Of course, each release means some work has to be done; then IIUC your point, the fewer releases the better. :-} > Am Tue, 30 Dec 2014 02:05:29 > +0100 schrieb Gilles : > >> On Mon, 29 Dec 2014 10:54:59 +, sebb wrote: >> > On 29 December 2014 at 10:36, Gilles >> >> > wrote: >> >> On Sun, 28 Dec 2014 20:21:32 -0700, Phil Steitz wrote: >> >>> >> >>> On 12/28/14 11:46 AM, Gilles wrote: >> >>>> >> >>>> Hi. >> >>>> >> >>>> On Sun, 28 Dec 2014 09:43:34 +0100, Luc Maisonobe wrote: >> >>>>> >> >>>>> Le 28/12/2014 00:22, sebb a écrit : >> >>>>>> >> >>>>>> On 27 December 2014 at 22:19, Gilles >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> On Sat, 27 Dec 2014 17:48:05 +, sebb wrote: >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On 24 December 2014 at 15:11, Gilles >> >>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> On Wed, 24 Dec 2014 15:52:12 +0100, Luc Maisonobe wrote: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> Le 24/12/2014 15:04, Gilles a écrit : >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> On Wed, 24 Dec 2014 09:31:46 +0100, Luc Maisonobe >> >>>>>>>>>>> wrote: >> >>>>>>>>>>>> >> >>>>>&g
Re: [Math] What's in a release
On Tue, 30 Dec 2014 01:48:20 +, sebb wrote: On 30 December 2014 at 01:36, Bernd Eckenfels wrote: Hello, Am Tue, 30 Dec 2014 02:29:38 +0100 schrieb Gilles : On Tue, 30 Dec 2014 02:09:42 +0100, Bernd Eckenfels wrote: > That thread gets deep. :) > > I just wanted to comment on "releasing only > source is faster because of less checks". I disagree with that, most > release delay/time is due to preparation work. Failed (binary) > checks are typically for a reason which would also be present in > the source (especially the POM), so it does not really reduce the > number of rework. RM is a streamlined procedure: so, if you do (say) 10 steps rather than 15, it will objectively take less time, and this is compounded by the additional tests which should (ideally) be performed by the reviewers. [Thus delaying the release.] The problem is not the small additional time for the last 5 steps but the large time for redoing all steps (on veto). > (At least not in most cases, so two votes will actually make us > more work not less). The additional work exactly amounts to sending _one_ additional mail. The actual work is not the vote mail but the people doing the preparation and the review. Then, as I noted, * some releases will be done as before (same work) * some releases will be "source only" (less work) Not much, you still have to check if the source actually works and can be build, produces sane archives and so on. * some releases will be two-steps, possibly performed by two different people (i.e. less work for each RM) And more work in sum, not only for the RMs but also the reviewers. (and the users which want to use the source release with maven like anybody there days) But I dont mind, if a project wants to do a source release only, thats fine with me, I just don't see the advantage. How many end users just want a source release anyway? I would expect most users to use the Maven jars, some will use the ASF binaries, and a few will use the ASF source (AIUI Linux distros often build from source). So, you answered your own question. Even if only the source is released, it's still necessary for the RM and reviewers to build and test it. Never said otherwise. [Testing the sources is one git command and one maven command. Testing the binaries requires downloading each of them and check the signatures and/or checksums, each a separate command.] Gilles Gruss Bernd Of course, each release means some work has to be done; then IIUC your point, the fewer releases the better. :-} > Am Tue, 30 Dec 2014 02:05:29 > +0100 schrieb Gilles : > >> On Mon, 29 Dec 2014 10:54:59 +, sebb wrote: >> > On 29 December 2014 at 10:36, Gilles >> >> > wrote: >> >> On Sun, 28 Dec 2014 20:21:32 -0700, Phil Steitz wrote: >> >>> >> >>> On 12/28/14 11:46 AM, Gilles wrote: >> >>>> >> >>>> Hi. >> >>>> >> >>>> On Sun, 28 Dec 2014 09:43:34 +0100, Luc Maisonobe wrote: >> >>>>> >> >>>>> Le 28/12/2014 00:22, sebb a écrit : >> >>>>>> >> >>>>>> On 27 December 2014 at 22:19, Gilles >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> On Sat, 27 Dec 2014 17:48:05 +, sebb wrote: >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On 24 December 2014 at 15:11, Gilles >> >>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> On Wed, 24 Dec 2014 15:52:12 +0100, Luc Maisonobe wrote: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> Le 24/12/2014 15:04, Gilles a écrit : >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> On Wed, 24 Dec 2014 09:31:46 +0100, Luc Maisonobe >> >>>>>>>>>>> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Le 24/12/2014 03:36, Gilles a écrit : >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>
Re: [Math] What's in a release
On Tue, 30 Dec 2014 01:38:12 +, sebb wrote: On 30 December 2014 at 01:29, Gilles wrote: On Tue, 30 Dec 2014 02:09:42 +0100, Bernd Eckenfels wrote: That thread gets deep. :) I just wanted to comment on "releasing only source is faster because of less checks". I disagree with that, most release delay/time is due to preparation work. Failed (binary) checks are typically for a reason which would also be present in the source (especially the POM), so it does not really reduce the number of rework. RM is a streamlined procedure: so, if you do (say) 10 steps rather than 15, it will objectively take less time, and this is compounded by the additional tests which should (ideally) be performed by the reviewers. [Thus delaying the release.] (At least not in most cases, so two votes will actually make us more work not less). The additional work exactly amounts to sending _one_ additional mail. No. Both source and binary release need to be checked and voted on. And the votes need to be tallied, and successful releases have to be published, and unsuccessful ones dropped. Yes, so? If a certain RC would be vetoed only because of a problem with the binaries? The source could have otherwise been released. Checking the source release requires (for the reviewer) downloading all the artifacts and tags. If the releases are separated in time some of this may have to be repeated. What "may have to be repeated" exactly? You wouldn't have to repeat whatever has been succesfully voted on. If source was released, you'd only have to check the binaries (signature), not the repository. Even for the RM role, it is more work overall. Then, as I noted, * some releases will be done as before (same work) * some releases will be "source only" (less work) * some releases will be two-steps, possibly performed by two different people (i.e. less work for each RM) Of course, each release means some work has to be done; then IIUC your point, the fewer releases the better. :-} I'm sorry, but I think you are glossing over several stages in your presentation of the process. If you really think your process is going to save work, please detail the exact stages necessary in both cases. Why do you see this in black or white? I never (and I repeated that several times already) intended to ask that all RM perform a two-step procedure: Anyone willing to RM as usual will obviously do it as he pleases. Every time the issue of "we should release more often" comes up, almost everyone agrees. Every time a discussion occurs on the RM issue, several people complain about the complexity of the procedure. I then propose something to _try_ and improve that situation (sometimes) and suddenly, the current procedure is found more efficient than ever. This information will be needed anyway as documentation if it is ever agreed upon. For source-only release, the information is the same as compiled by Luc (leaving out the Nexus-related steps and possibly replacing the bunch of files copied to "https://dist.apache.org/repos/dist"; with the tarball referred to previously). IMO, the contradiction is obvious between talk of releasing source-only and nit-picking that amounts to actually refuse to consider source-only releases. Good night, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] What's in a release
On Tue, 30 Dec 2014 02:12:51 +, sebb wrote: On 30 December 2014 at 02:06, Gilles wrote: On Tue, 30 Dec 2014 01:48:20 +, sebb wrote: On 30 December 2014 at 01:36, Bernd Eckenfels wrote: Hello, Am Tue, 30 Dec 2014 02:29:38 +0100 schrieb Gilles : On Tue, 30 Dec 2014 02:09:42 +0100, Bernd Eckenfels wrote: > That thread gets deep. :) > > I just wanted to comment on "releasing only > source is faster because of less checks". I disagree with that, most > release delay/time is due to preparation work. Failed (binary) > checks are typically for a reason which would also be present in > the source (especially the POM), so it does not really reduce the > number of rework. RM is a streamlined procedure: so, if you do (say) 10 steps rather than 15, it will objectively take less time, and this is compounded by the additional tests which should (ideally) be performed by the reviewers. [Thus delaying the release.] The problem is not the small additional time for the last 5 steps but the large time for redoing all steps (on veto). > (At least not in most cases, so two votes will actually make us > more work not less). The additional work exactly amounts to sending _one_ additional mail. The actual work is not the vote mail but the people doing the preparation and the review. Then, as I noted, * some releases will be done as before (same work) * some releases will be "source only" (less work) Not much, you still have to check if the source actually works and can be build, produces sane archives and so on. * some releases will be two-steps, possibly performed by two different people (i.e. less work for each RM) And more work in sum, not only for the RMs but also the reviewers. (and the users which want to use the source release with maven like anybody there days) But I dont mind, if a project wants to do a source release only, thats fine with me, I just don't see the advantage. How many end users just want a source release anyway? I would expect most users to use the Maven jars, some will use the ASF binaries, and a few will use the ASF source (AIUI Linux distros often build from source). So, you answered your own question. Even if only the source is released, it's still necessary for the RM and reviewers to build and test it. Never said otherwise. [Testing the sources is one git command and one maven command. Not so. The source archive has to be downloaded, and its sigs and hashes checked. It also has to be compared against the SCM tag, and the N&L files checked. (1) download == git clone tag_url --> No download of a signed archive. (2) git tag -v tag_name (3) build == maven test site [Sorry: that was 3 commands.] Then maybe people in the know can examine the license issues, like you did. But I hardly count that every reviewer would do it. [Besides, it should have been done at the time the code was introduced. And, as I said in the other thread, we might seriously need to consider requesting an actual legal review if the matter is so sensitive: Submit to a lawyer when the contents is changed; no need to check when the contents is left untouched.] Testing the binaries requires downloading each of them and check the signatures and/or checksums, each a separate command.] The files can be downloaded as a single bunch, especially if one uses the SVN dist/dev staging area. It's easy enough to write shell scripts to check all hashes and sigs in a single directory. When I've asked at this thread's start (under subject "Git question"), the answer was that this does not strictly prove the link between source code and binaries. Hence the attempt to segregate what can be proved from what cannot. Back to square one. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] What's in a release
On Tue, 30 Dec 2014 03:05:57 +, sebb wrote: On 30 December 2014 at 02:40, Gilles wrote: On Tue, 30 Dec 2014 01:38:12 +, sebb wrote: On 30 December 2014 at 01:29, Gilles wrote: On Tue, 30 Dec 2014 02:09:42 +0100, Bernd Eckenfels wrote: That thread gets deep. :) I just wanted to comment on "releasing only source is faster because of less checks". I disagree with that, most release delay/time is due to preparation work. Failed (binary) checks are typically for a reason which would also be present in the source (especially the POM), so it does not really reduce the number of rework. RM is a streamlined procedure: so, if you do (say) 10 steps rather than 15, it will objectively take less time, and this is compounded by the additional tests which should (ideally) be performed by the reviewers. [Thus delaying the release.] (At least not in most cases, so two votes will actually make us more work not less). The additional work exactly amounts to sending _one_ additional mail. No. Both source and binary release need to be checked and voted on. And the votes need to be tallied, and successful releases have to be published, and unsuccessful ones dropped. Yes, so? I was just pointing out that separate source and binary releases are more than just an additional e-mail. The total effort is bigger. Also it's usually less efficient to split the same jobs over two sessions because of the extra prep. Which is easier - committing the same change to two files as one commit or two at different times? If a certain RC would be vetoed only because of a problem with the binaries? The source could have otherwise been released. Yes, but how frequent is that? Usually there is an issue with the source that has caused the issue. Besides, how many Commons users want just the source? Checking the source release requires (for the reviewer) downloading all the artifacts and tags. If the releases are separated in time some of this may have to be repeated. What "may have to be repeated" exactly? Downloading the tag is one step that may have to be repeated. I also check the sigs against the current KEYS file by loading that into a temp GPG keyring. You wouldn't have to repeat whatever has been succesfully voted on. If source was released, you'd only have to check the binaries (signature), not the repository. Even for the RM role, it is more work overall. Then, as I noted, * some releases will be done as before (same work) * some releases will be "source only" (less work) * some releases will be two-steps, possibly performed by two different people (i.e. less work for each RM) Of course, each release means some work has to be done; then IIUC your point, the fewer releases the better. :-} I'm sorry, but I think you are glossing over several stages in your presentation of the process. If you really think your process is going to save work, please detail the exact stages necessary in both cases. Why do you see this in black or white? I'm not; I'm trying to understand the two approaches in order to compare them. I never (and I repeated that several times already) intended to ask that all RM perform a two-step procedure: Anyone willing to RM as usual will obviously do it as he pleases. Every time the issue of "we should release more often" comes up, almost everyone agrees. Every time a discussion occurs on the RM issue, several people complain about the complexity of the procedure. I then propose something to _try_ and improve that situation (sometimes) and suddenly, the current procedure is found more efficient than ever. That is not an accurate summary of what I wrote. It is an interpretation of the consequence of what you write: no gain whatsoever, in no circumstances. You cannot prove that, yet you ask me to prove that there could be a gain; it's not fair. I just don't see how performing the release in separate stages is going to help reduce the total work done. This is black and white. My position is that, in some cases (however rare maybe-but-we-don't-know-since-you-don't-even-want-to-try), it might be useful to vote on a source-only release. You gave one example (linux distributions), I gave one (urgent fix/feature). Why should we argue on the overall time saved, or not, rather than agree on the principle (even if it proves useless _most_ of the time)? This information will be needed anyway as documentation if it is ever agreed upon. For source-only release, the information is the same as compiled by Luc (leaving out the Nexus-related steps and possibly replacing the bunch of files copied to "https://dist.apache.org/repos/dist"; with the tarball referred to previously). IMO, the contradiction is obvious between talk of releasing source-only and nit-picking that amounts to actually refuse to consider source-onl
Re: [Math] What's in a release
On Tue, 30 Dec 2014 03:22:32 +, sebb wrote: On 30 December 2014 at 03:05, Gilles wrote: On Tue, 30 Dec 2014 02:12:51 +, sebb wrote: On 30 December 2014 at 02:06, Gilles wrote: On Tue, 30 Dec 2014 01:48:20 +, sebb wrote: On 30 December 2014 at 01:36, Bernd Eckenfels wrote: Hello, Am Tue, 30 Dec 2014 02:29:38 +0100 schrieb Gilles : On Tue, 30 Dec 2014 02:09:42 +0100, Bernd Eckenfels wrote: > That thread gets deep. :) > > I just wanted to comment on "releasing only > source is faster because of less checks". I disagree with that, most > release delay/time is due to preparation work. Failed (binary) > checks are typically for a reason which would also be present in > the source (especially the POM), so it does not really reduce the > number of rework. RM is a streamlined procedure: so, if you do (say) 10 steps rather than 15, it will objectively take less time, and this is compounded by the additional tests which should (ideally) be performed by the reviewers. [Thus delaying the release.] The problem is not the small additional time for the last 5 steps but the large time for redoing all steps (on veto). > (At least not in most cases, so two votes will actually make us > more work not less). The additional work exactly amounts to sending _one_ additional mail. The actual work is not the vote mail but the people doing the preparation and the review. Then, as I noted, * some releases will be done as before (same work) * some releases will be "source only" (less work) Not much, you still have to check if the source actually works and can be build, produces sane archives and so on. * some releases will be two-steps, possibly performed by two different people (i.e. less work for each RM) And more work in sum, not only for the RMs but also the reviewers. (and the users which want to use the source release with maven like anybody there days) But I dont mind, if a project wants to do a source release only, thats fine with me, I just don't see the advantage. How many end users just want a source release anyway? I would expect most users to use the Maven jars, some will use the ASF binaries, and a few will use the ASF source (AIUI Linux distros often build from source). So, you answered your own question. Even if only the source is released, it's still necessary for the RM and reviewers to build and test it. Never said otherwise. [Testing the sources is one git command and one maven command. Not so. The source archive has to be downloaded, and its sigs and hashes checked. It also has to be compared against the SCM tag, and the N&L files checked. (1) download == git clone tag_url --> No download of a signed archive. But the signed archive is what is released. The ASF releases open source which is distributed from the ASF mirror system. So the signed archive is a fundamental part of the RC vote. So it's either that or point (2). [Both check the signature of the source code.] (2) git tag -v tag_name No idea what that does. Cf. previous paragraph. (3) build == maven test site [Sorry: that was 3 commands.] Then maybe people in the know can examine the license issues, like you did. But I hardly count that every reviewer would do it. [Besides, it should have been done at the time the code was introduced. And, as I said in the other thread, we might seriously need to consider requesting an actual legal review if the matter is so sensitive: Submit to a lawyer when the contents is changed; no need to check when the contents is left untouched.] The contents is potentially changed with every commit. Yes, the N&L files should be kept up to date as each commit is added. However, this is not always done, so it's important to check them before release. I contend that there should be a big fat warning that those files should not be modified lightly. And if they are, an issue _must_ be opened on the bug-tracking system with the rationale for the new contents, or a request that knwoledgeable people examine the situation. Testing the binaries requires downloading each of them and check the signatures and/or checksums, each a separate command.] The files can be downloaded as a single bunch, especially if one uses the SVN dist/dev staging area. It's easy enough to write shell scripts to check all hashes and sigs in a single directory. When I've asked at this thread's start (under subject "Git question"), the answer was that this does not strictly prove the link between source code and binaries. Hence the attempt to segregate what can be proved from what cannot. Back to square one. Provable provenance is only part of what the vote should be about. It's not possible in general to prove that a binary is derived from a source. However, it is possible to document
Re: [Math] Missing documentation for ParameterValidator
On Tue, 30 Dec 2014 08:27:24 -0500, Bruce A Johnson wrote: When I click on the documentation link ( at http://commons.apache.org/proper/commons-math/apidocs/index.html <http://commons.apache.org/proper/commons-math/apidocs/index.html> ) for ParameterValidator in the fitting.leastsquares package I get: The requested URL /proper/commons-math/javadocs/api-3.4/org/apache/commons/math3/fitting/leastsquares/ParameterValidator.html was not found on this server. You are right. It's strange. The problem does not seem to be with the generation of the apidocs during the build (the page exists on my machine). Perhaps a glitch during the transmission over to the Apache server? Could you please file a report on the bug-tracking system? Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Math] HTML files
Hi. While looking at MATH-1184, I notice that the HTML files in the repository have this line: ---CUT--- ---CUT--- When I generate them, I have ---CUT--- ---CUT--- Which version should be under svn? Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Math] Possibly wrong fix for MATH-1184
Hello. I don't think I've followed the correct path for updating the web site to fix MATH-1184. Reading the "release howto" I understood that I could modify the checked-out repository and do "svn commit"; it worked and the missing files are now available from the web server. But reading further into the notes, I don't understand anymore: there is a mention of the "staging area" but that one stayed empty, and then, of using a link to publish the site (which I didn't do, yet published it was). Clarifications are needed... Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Possibly wrong fix for MATH-1184
On Tue, 30 Dec 2014 21:48:04 +, sebb wrote: On 30 December 2014 at 19:41, Luc Maisonobe wrote: Le 30/12/2014 19:30, Gilles a écrit : Hello. I don't think I've followed the correct path for updating the web site to fix MATH-1184. Reading the "release howto" I understood that I could modify the checked-out repository and do "svn commit"; it worked and the missing files are now available from the web server. But reading further into the notes, I don't understand anymore: there is a mention of the "staging area" but that one stayed empty, and then, of using a link to publish the site (which I didn't do, yet published it was). Clarifications are needed... It should depend on the origin from which your repository was first checked out. If it was https://svn.apache.org/repos/infra/websites/staging then it points to the staging area, whereas if it was https://svn.apache.org/repos/infra/websites/production, then it directly points to the live site. It now seems to me the automatic checkout done by maven uses already the production part, so the staging part is not used. Looking into the staging area (using svn ls), it seems to contain only top level stuff (probably commons-site) and not components. The instructions in the release howto indicates: svn checkout https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-math It's clear that by following that, I directly updated the "production" site; hence my wondering about the following step involving https://cms.apache.org/commons/publish which in that case should do nothing since the "staging" area is empty... AIUI the staging areas are only used by the CMS system. One edits the source using CMS and it is built into the (shared) staging area. Assuming no-one else publishes it first (!) this allows one to review the changes. Publication involves updating production from staging. The website document area consists of a workspace for the production area. This is updated by svnpubsub when the production area changes. There is no instruction on "svnpubsub" in the CM's release howto. I updated the "latest" apidocs. Is there a way to also fix the "api-3.4" directory. What is the recommended way to go from the local site created with "mvn site" to the "staging" to the location corresponding to release X.y ? Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Committing Code, JIRA Gardening
On Sat, 3 Jan 2015 18:01:22 +, sebb wrote: On 3 January 2015 at 12:32, Benedikt Ritter wrote: Hello Carl, 2015-01-03 2:49 GMT+01:00 Carl Hall : Thanks, Benedikt and Mark. I have made my first commit (woo!) and will start working through JIRA to clear out the easy stuff. Is there any rule (by writ or general practice) for closing tickets that haven't seen any action in some time? Seems like old tickets that haven't moved in a while (e.g. [1]) might be candidates for "reopen if this becomes interesting again." There is no strict procedure for this kind of issues. In your particular case, Sebb has already commented that this addition doesn't really make sense. Since the contributor hasn't reacted on the comment, I think it's okay to close this issue as Won't fix. Note, that we only set the Fix Version for issues that have actually been implemented. So when an issue is closed as Won't fix, duplicate, invalid etc, we remove the fix version, so that it doesn't show up in the reports for this version. In many components the fix version is only added when the fix is actually implemented. i.e. it is treated as "has been fixed in version x" rather than "this is an issue to be fixed in version x" JIRA allows both (when the issue is created and when it is resolved). Setting the "Fix version" allows a clearer view of what needs to be done before the next release can happen. Gilles [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math][dbcp][pool] Apachecon NA (Austin)
On Fri, 02 Jan 2015 14:45:15 -0700, Phil Steitz wrote: I am thinking about submitting a proposal or two for Austin. I could update / extend the pool/dbcp talk I did last year or try a [math] talk. I would love to have company developing and / or presenting either of these. Is anyone else interested in working on a talk on either of these? Any suggestions on content? For [math] I have always wanted to do a high level overview followed by some real world examples. It would be great to make the examples part a community effort. It reminded me that I had yet to improve one toy example in the "src/userguide/java/org/apache/commons/math3/userguide" section of the repository. It also occurred to me that I don't know how to compile and run the applications stored there. :( Is there a maven incantation to do so? For [pool] / [dbcp] I did the boring part last year - summary of changes in the 2.x versions, migration, etc. - so this year I could focus on examples and best practices. Again, a great thing to work together on. Another crazy idea I have had is a talk on how hard it is to design stable APIs, using [math] as an example. Is it really hard? Isn't it rather that some developers just lack the willpower to support less than ideal APIs? :-} That talk would also call out some of the special challenges that you run into modelling mathematical objects using OO constructs. That would be interesting. Are mathematical concepts really more special to model than other concepts? I rather think that the issues arise from trying to sort out the general from the particular, trying to implement generic algorithms to solve as many practical problems as possible. This quite naturally lead to desing decisions that may be challenged by the appearance of unforeseen cases (or better programming skills). Might be a little painful to develop, but also maybe a little cathartic ;) It would certainly be useful to understand where the pain really comes from. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math][dbcp][pool] Apachecon NA (Austin)
Hello. On Sun, 04 Jan 2015 12:09:35 +0100, Luc Maisonobe wrote: Hi all, Le 04/01/2015 02:07, Gilles a écrit : On Fri, 02 Jan 2015 14:45:15 -0700, Phil Steitz wrote: I am thinking about submitting a proposal or two for Austin. I could update / extend the pool/dbcp talk I did last year or try a [math] talk. I would love to have company developing and / or presenting either of these. Is anyone else interested in working on a talk on either of these? Any suggestions on content? For [math] I have always wanted to do a high level overview followed by some real world examples. It would be great to make the examples part a community effort. It reminded me that I had yet to improve one toy example in the "src/userguide/java/org/apache/commons/math3/userguide" section of the repository. It also occurred to me that I don't know how to compile and run the applications stored there. :( Is there a maven incantation to do so? No as maven does not know about this directory (and should not IMHO). I think that we should have some way to 1. automatically compile its content (so that we can ensure that the source tree does not contain any non-compilable stuff) and 2. run selected classes (so that users easily see CM code at work) It looks like it should not be too difficult (for an experienced maven user, which I'm not) to create a profile for doing just that. [I've seen there is an "exec" plugin that could do (2), but I couldn't find where one can specifytan alternate source for compilation.] For [pool] / [dbcp] I did the boring part last year - summary of changes in the 2.x versions, migration, etc. - so this year I could focus on examples and best practices. Again, a great thing to work together on. Another crazy idea I have had is a talk on how hard it is to design stable APIs, using [math] as an example. Is it really hard? Isn't it rather that some developers just lack the willpower to support less than ideal APIs? :-} Yes, it is hard. I wanted to stress exactly what you expand below, i.e. that needs are changing, and that if we want to combine all the qualities of good code (a.o. code that evolves with the developers' community, with the users' community, with the language's state-of-the-art, with the computers' power, etc.) we have to modify the APIs; it is a never ending, but creative, task. The alternative is, as I wrote above, to stick with less-than-ideal APIs, and _that_ is not hard; but it is a dead end. That talk would also call out some of the special challenges that you run into modelling mathematical objects using OO constructs. That would be interesting. Are mathematical concepts really more special to model than other concepts? No, the problem is that low level reusable components intended to be used by lots of different users for lots of different needs are difficult to set up. You have to meet conflicting needs and the developers do not know in advance how their code will be used. That's what I wrote below: "trying to implement generic algorithms to solve as many practical problems as possible". Thus: it is good to have generic, reusable, code (e.g. just from a maintenance POV), but it at some point, it will conflict with unexpected usage. Hence API change will be in order. In many cases, things start with "someone scratching an itch" because open-source developers are the first users of their stuff. The resulting API is biased towards this first need. Low level reusable components developers have to make lots of efforts to design something clean enough to anticipate other uses. Even experienced low level reusable components developers don't succeed in this part. I totally and did not say otherwise. The wrong way would be to have duplicate code all over the place to tak care of each new usage. Since we try to avoid that, we'll need to refactor when the "genericity" in one direction conflicts with unanticipated usage. I rather think that the issues arise from trying to sort out the general from the particular, trying to implement generic algorithms to solve as many practical problems as possible. Perhaps, but it is really an important need for reusable components. From a development POV, I thinks so too. For black-box users, it is not. [They don't care about what's in the box as long as it does the job; and "no duplicate code" is, for instance, not a requirement. But this a short-term view, since maintenance will suffer and loss of quality will ensue.] Another problem is that not moving forward (typically still staying in the 3.X series instead of starting 4.0) creates additional constraints. Trying to patch something wrong is much more difficult than rewriting it, and sometimes it is even completely impossible if wrong design choices cannot be changed. +1 This quite naturally lead to desing decisions that
[Math] Maven profile for running the examples?
Hi. In the "src/userguide/java" directory, there are a few self-contained usage examples. I think that we should have some way to 1. automatically compile its content (so that we can ensure that the source tree does not contain any non-compilable stuff) and 2. run selected classes (so that users easily see CM code at work) It looks like it should not be too difficult (for an experienced maven user, which I'm not) to create a profile for doing just that. [I've seen there is an "exec" plugin that could do (2), but I didn't find where, in the "pom.xml", one can specify an alternate directory for indicating which sources to compile.] Thanks for any hint, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Maven profile for running the examples?
On Sun, 4 Jan 2015 20:31:30 +, sebb wrote: Did you see my mail from earlier today titled as below ? Compiling and running examples No, I missed it! This explains how Commons NET examples are built and used. Thanks for the reminder, Gilles On 4 January 2015 at 18:21, Gilles wrote: Hi. In the "src/userguide/java" directory, there are a few self-contained usage examples. I think that we should have some way to 1. automatically compile its content (so that we can ensure that the source tree does not contain any non-compilable stuff) and 2. run selected classes (so that users easily see CM code at work) It looks like it should not be too difficult (for an experienced maven user, which I'm not) to create a profile for doing just that. [I've seen there is an "exec" plugin that could do (2), but I didn't find where, in the "pom.xml", one can specify an alternate directory for indicating which sources to compile.] Thanks for any hint, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Compiling and running examples [was [math][dbcp][pool] Apachecon NA (Austin))
On Sun, 4 Jan 2015 14:20:53 +, sebb wrote: On 4 January 2015 at 12:58, Gilles wrote: Hello. On Sun, 04 Jan 2015 12:09:35 +0100, Luc Maisonobe wrote: Hi all, Le 04/01/2015 02:07, Gilles a écrit : It reminded me that I had yet to improve one toy example in the "src/userguide/java/org/apache/commons/math3/userguide" section of the repository. It also occurred to me that I don't know how to compile and run the applications stored there. :( Is there a maven incantation to do so? No as maven does not know about this directory (and should not IMHO). I think that we should have some way to 1. automatically compile its content (so that we can ensure that the source tree does not contain any non-compilable stuff) and 2. run selected classes (so that users easily see CM code at work) It looks like it should not be too difficult (for an experienced maven user, which I'm not) to create a profile for doing just that. [I've seen there is an "exec" plugin that could do (2), but I couldn't find where one can specifytan alternate source for compilation.] Commons NET has an examples/ tree which is compiled and released as a separate bundle. Note that this is under src/main/java, not under the userguide, but it should be relatively easy to maintain the examples there and copy to (or link from) the userguide. The NET examples jar has a feature you might find useful. It defines the Main-Class and the Class-Path. This means it can be invoked using java -jar commons-net-examples.jar ExampleName parameters. This indeed looks like a easy way to run the code. This assumes that the user has put the examples and main net jars in the same directory. Would everyone agree to move the "userguide" code into the "main" directory? [Of course, this would imply that we need to modify the "pom.xml" in order to exclude the "userguide" code from the CM library JAR.] Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math][dbcp][pool] Apachecon NA (Austin)
Hi.
On Sun, 04 Jan 2015 14:37:41 -0700, Phil Steitz wrote:
On 1/4/15 5:58 AM, Gilles wrote:
Hello.
On Sun, 04 Jan 2015 12:09:35 +0100, Luc Maisonobe wrote:
Hi all,
Le 04/01/2015 02:07, Gilles a écrit :
On Fri, 02 Jan 2015 14:45:15 -0700, Phil Steitz wrote:
I am thinking about submitting a proposal or two for Austin. I
could update / extend the pool/dbcp talk I did last year or try a
[math] talk. I would love to have company developing and / or
presenting either of these. Is anyone else interested in
working on
a talk on either of these? Any suggestions on content?
For [math] I have always wanted to do a high level overview
followed
by some real world examples. It would be great to make the
examples
part a community effort.
It reminded me that I had yet to improve one toy example in the
"src/userguide/java/org/apache/commons/math3/userguide" section
of the repository.
It also occurred to me that I don't know how to compile and run
the applications stored there. :(
Is there a maven incantation to do so?
No as maven does not know about this directory (and should not
IMHO).
I think that we should have some way to
1. automatically compile its content (so that we can ensure that the
source tree does not contain any non-compilable stuff) and
2. run selected classes (so that users easily see CM code at work)
It looks like it should not be too difficult (for an experienced
maven user, which I'm not) to create a profile for doing just that.
[I've seen there is an "exec" plugin that could do (2), but I
couldn't find where one can specifytan alternate source for
compilation.]
For [pool] / [dbcp] I did the boring part last year - summary of
changes in the 2.x versions, migration, etc. - so this year I
could
focus on examples and best practices. Again, a great thing to
work
together on.
Another crazy idea I have had is a talk on how hard it is to
design
stable APIs, using [math] as an example.
Is it really hard? Isn't it rather that some developers just lack
the willpower to support less than ideal APIs? :-}
Yes, it is hard.
I wanted to stress exactly what you expand below, i.e. that needs
are
changing, and that if we want to combine all the qualities of good
code (a.o. code that evolves with the developers' community, with
the users' community, with the language's state-of-the-art, with the
computers' power, etc.) we have to modify the APIs; it is a never
ending, but creative, task.
The alternative is, as I wrote above, to stick with less-than-ideal
APIs, and _that_ is not hard; but it is a dead end.
If you make good choices initially, it does not have to be a dead
end. That's the challenge.
Getting it right from the outset is indeed hard.
In my own, obviously limited, programming experience, it _never_
occurred.
Since, as Luc mentioned, development in CM (almost?) is always the
result of some definite (and more or less urgent) need of a single
developer, it looks pretty impossible to assume that we can get it
right from the outset. That is, unless we change the policy "that
whoever does the job...": it should rather become that whoever
does the job must show ("prove") that there is no better way to
implement the proposed functionality, which, needless to say, would
put all development to a final rest!
Some of our APIs have been pretty
stable.
IMHO, some would benefit from being changed. I mean that some are
not stable because they are the best that can be, but because the
emphasis is on stability.
The problem with constantly changing APIs is they become
effectively worthless for real world use.
It depends. Strictly it is not true, as I've mentioned several
times: people who are happy with some version "A.b" do not have
to change anything, ever. Furthermore they can benefit from
new features (and refactoring) in version "C.d" by using another
JAR along the old one.
The sole problem here is that we don't want to maintain old
versions.
Even for me, as a *math
developer*, I have some of my own hacked / forked / semi-patched
versions of [math] things because I don't have time to refactor and
retest all of the code that uses now compat-broken stuff.
According to the above, that's because of your decision to not
use older CM libraries.
I am not
advocating that we don't ever change APIs - just that we be
conservative in doing so so that users can count on some level of
stability.
I'm of the opinion that it should not be at the expense of the
other qualities of "good code".
Somehow R does this pretty well.
The last comment is what I was thinking about exploring when I said
that modeling math algorithms using OO constructs is tricky. Maybe
they are just much smarter than us (to some extent, I am sure that
is true); but I think R also has the advantage that it is really a
pretty much procedural setup (I know,
Re: [math][dbcp][pool] Apachecon NA (Austin)
On Mon, 5 Jan 2015 16:15:34 +, sebb wrote:
On 5 January 2015 at 15:54, Phil Steitz
wrote:
On 1/5/15 5:39 AM, Gilles wrote:
Hi.
On Sun, 04 Jan 2015 14:37:41 -0700, Phil Steitz wrote:
On 1/4/15 5:58 AM, Gilles wrote:
Hello.
On Sun, 04 Jan 2015 12:09:35 +0100, Luc Maisonobe wrote:
Hi all,
Le 04/01/2015 02:07, Gilles a écrit :
On Fri, 02 Jan 2015 14:45:15 -0700, Phil Steitz wrote:
I am thinking about submitting a proposal or two for Austin.
I
could update / extend the pool/dbcp talk I did last year or
try a
[math] talk. I would love to have company developing and / or
presenting either of these. Is anyone else interested in
working on
a talk on either of these? Any suggestions on content?
For [math] I have always wanted to do a high level overview
followed
by some real world examples. It would be great to make the
examples
part a community effort.
It reminded me that I had yet to improve one toy example in the
"src/userguide/java/org/apache/commons/math3/userguide" section
of the repository.
It also occurred to me that I don't know how to compile and run
the applications stored there. :(
Is there a maven incantation to do so?
No as maven does not know about this directory (and should not
IMHO).
I think that we should have some way to
1. automatically compile its content (so that we can ensure that
the
source tree does not contain any non-compilable stuff) and
2. run selected classes (so that users easily see CM code at
work)
It looks like it should not be too difficult (for an experienced
maven user, which I'm not) to create a profile for doing just
that.
[I've seen there is an "exec" plugin that could do (2), but I
couldn't find where one can specifytan alternate source for
compilation.]
For [pool] / [dbcp] I did the boring part last year - summary
of
changes in the 2.x versions, migration, etc. - so this year I
could
focus on examples and best practices. Again, a great thing to
work
together on.
Another crazy idea I have had is a talk on how hard it is to
design
stable APIs, using [math] as an example.
Is it really hard? Isn't it rather that some developers just
lack
the willpower to support less than ideal APIs? :-}
Yes, it is hard.
I wanted to stress exactly what you expand below, i.e. that
needs are
changing, and that if we want to combine all the qualities of
good
code (a.o. code that evolves with the developers' community, with
the users' community, with the language's state-of-the-art, with
the
computers' power, etc.) we have to modify the APIs; it is a never
ending, but creative, task.
The alternative is, as I wrote above, to stick with
less-than-ideal
APIs, and _that_ is not hard; but it is a dead end.
If you make good choices initially, it does not have to be a dead
end. That's the challenge.
Getting it right from the outset is indeed hard.
In my own, obviously limited, programming experience, it _never_
occurred.
I agree its hard. I think we have actually succeeded in a few
places. For example, the PRNG framework has been stable since first
release. Admittedly, the core interface is just extracted from
java.util.random, but the the abstract superclass and framework for
the generators has worked very well. Another example is the
distributions package. Other than fiddling with sampling, the core
there has been stable since 1.x (10+ years now). We have added /
extended capabilities and many, many distributions; but very little
incompatible change.
Since, as Luc mentioned, development in CM (almost?) is always the
result of some definite (and more or less urgent) need of a single
developer, it looks pretty impossible to assume that we can get it
right from the outset. That is, unless we change the policy "that
whoever does the job...": it should rather become that whoever
does the job must show ("prove") that there is no better way to
implement the proposed functionality, which, needless to say, would
put all development to a final rest!
Personally I think that when we add things - and more importantly
when we consider changing existing APIs - we do need to think about
extensibility and how to model the problem. The benefit of having a
community is that it does not have to be "one developer solving his
/ her problem." The itch can certainly come from one developer, but
the solution belongs to the community.
Some of our APIs have been pretty
stable.
IMHO, some would benefit from being changed. I mean that some are
not stable because they are the best that can be, but because the
emphasis is on stability.
The problem with constantly changing APIs is they become
effectively worthless for real world use.
It depends. Strictly it is not true, as I've mentioned several
times: people who are happy with some version "A.b" do not have
to change anything, ever. Furthermore they can benefit from
new features (and
Re: [Math] Maven profile for running the examples?
On Sun, 4 Jan 2015 20:31:30 +, sebb wrote: Did you see my mail from earlier today titled as below ? Compiling and running examples This explains how Commons NET examples are built and used. Copy-pasting Sebb's proposal from the other thread: [Examples] can be invoked using java -jar commons-net-examples.jar ExampleName parameters. This assumes that the user has put the examples and main net jars in the same directory. Would everyone agree to move the "userguide" code into the "main" directory? [Of course, this would imply that we need to modify the "pom.xml" in order to exclude the "userguide" code from the CM library JAR.] Please let me know if this solution is fine, so that I can modify the CM's "pom.xml" file and move the code accordingly. Thanks, Gilles On 4 January 2015 at 18:21, Gilles wrote: Hi. In the "src/userguide/java" directory, there are a few self-contained usage examples. I think that we should have some way to 1. automatically compile its content (so that we can ensure that the source tree does not contain any non-compilable stuff) and 2. run selected classes (so that users easily see CM code at work) It looks like it should not be too difficult (for an experienced maven user, which I'm not) to create a profile for doing just that. [I've seen there is an "exec" plugin that could do (2), but I didn't find where, in the "pom.xml", one can specify an alternate directory for indicating which sources to compile.] Thanks for any hint, Gilles For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Maven profile for running the examples?
On Mon, 05 Jan 2015 20:43:18 +0100, Luc Maisonobe wrote: Le 05/01/2015 18:41, Gilles a écrit : On Sun, 4 Jan 2015 20:31:30 +, sebb wrote: Did you see my mail from earlier today titled as below ? Compiling and running examples This explains how Commons NET examples are built and used. Copy-pasting Sebb's proposal from the other thread: [Examples] can be invoked using java -jar commons-net-examples.jar ExampleName parameters. This assumes that the user has put the examples and main net jars in the same directory. Would everyone agree to move the "userguide" code into the "main" directory? [Of course, this would imply that we need to modify the "pom.xml" in order to exclude the "userguide" code from the CM library JAR.] Please let me know if this solution is fine, so that I can modify the CM's "pom.xml" file and move the code accordingly. No problem for me, as long as maven can find the docs. Which docs? I didn't intend to move the "userguide" document; only the Java examples currently under "src/userguide/java" would be moved to "src/main" Gilles best regards, Luc Thanks, Gilles On 4 January 2015 at 18:21, Gilles wrote: Hi. In the "src/userguide/java" directory, there are a few self-contained usage examples. I think that we should have some way to 1. automatically compile its content (so that we can ensure that the source tree does not contain any non-compilable stuff) and 2. run selected classes (so that users easily see CM code at work) It looks like it should not be too difficult (for an experienced maven user, which I'm not) to create a profile for doing just that. [I've seen there is an "exec" plugin that could do (2), but I didn't find where, in the "pom.xml", one can specify an alternate directory for indicating which sources to compile.] Thanks for any hint, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Maven profile for running the examples?
On Mon, 5 Jan 2015 23:48:43 +0100, Bernd Eckenfels wrote: Am Mon, 05 Jan 2015 23:35:49 +0100 schrieb Gilles : Which docs? I didn't intend to move the "userguide" document; only the Java examples currently under "src/userguide/java" would be moved to "src/main" I wont mention multiple modules (also this might be a case where it makes sense, especially if you want to create a dedicated example jar file with its own set of dependencies and as it might avoid calling ant scripts for it), but I would keep the source separated and rather add an additional source directory (with the buildhelper). org.codehaus.mojo build-helper-maven-plugin initialize add-source src/userguide/java NB: this will produce classes on target/classes so you need to exclude them in the JAR. Thanks. I find it cleaner to keep the examples separated from the "main" code; so if this does the trick, I'd prefer it that way. We'd nevertheless need that separate JAR that contains the examples, and a mean to select which of the examples must be run, as proposed by Sebb. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Maven profile for running the examples?
On Tue, 06 Jan 2015 08:51:32 +0100, Thomas Neidhart wrote: On 01/05/2015 11:58 PM, Gilles wrote: On Mon, 5 Jan 2015 23:48:43 +0100, Bernd Eckenfels wrote: Am Mon, 05 Jan 2015 23:35:49 +0100 schrieb Gilles : Which docs? I didn't intend to move the "userguide" document; only the Java examples currently under "src/userguide/java" would be moved to "src/main" I wont mention multiple modules (also this might be a case where it makes sense, especially if you want to create a dedicated example jar file with its own set of dependencies and as it might avoid calling ant scripts for it), but I would keep the source separated and rather add an additional source directory (with the buildhelper). org.codehaus.mojo build-helper-maven-plugin initialize add-source src/userguide/java NB: this will produce classes on target/classes so you need to exclude them in the JAR. Thanks. I find it cleaner to keep the examples separated from the "main" code; so if this does the trick, I'd prefer it that way. We'd nevertheless need that separate JAR that contains the examples, and a mean to select which of the examples must be run, as proposed by Sebb. The examples can not be added to the main code as there is an additional dependency (xchart) that we do not want to add to commons-math in general. It was never intended to ship the examples as part of the CM library. [There are provisions in the "pom.xml" to prevent it (IIUC).] IIUC, Sebb proposed that the source code be moved solely for the purpose that maven would compile it with the default config. IIUC, with Bernd's proposal, this move is thus not necessary. An option would be to add it as part of the test code and use the "test" scope for the dependency but for exactly this reason it was decided to keep the two things apart (commons-math, userguide). I have no problem with that, quite the contrary as I write above. The original issue was: How do we run the examples? Phil proposed an "ant" script, which I would have happily produced. But then if "maven" can do it (with the suggested changes to the "pom.xml"), it's IMO simpler to not have to run a different program. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Maven profile for running the examples?
On Tue, 06 Jan 2015 17:49:35 +0100, Thomas Neidhart wrote: On 01/06/2015 12:58 PM, Gilles wrote: On Tue, 06 Jan 2015 08:51:32 +0100, Thomas Neidhart wrote: On 01/05/2015 11:58 PM, Gilles wrote: On Mon, 5 Jan 2015 23:48:43 +0100, Bernd Eckenfels wrote: Am Mon, 05 Jan 2015 23:35:49 +0100 schrieb Gilles : Which docs? I didn't intend to move the "userguide" document; only the Java examples currently under "src/userguide/java" would be moved to "src/main" I wont mention multiple modules (also this might be a case where it makes sense, especially if you want to create a dedicated example jar file with its own set of dependencies and as it might avoid calling ant scripts for it), but I would keep the source separated and rather add an additional source directory (with the buildhelper). org.codehaus.mojo build-helper-maven-plugin initialize add-source src/userguide/java NB: this will produce classes on target/classes so you need to exclude them in the JAR. Thanks. I find it cleaner to keep the examples separated from the "main" code; so if this does the trick, I'd prefer it that way. We'd nevertheless need that separate JAR that contains the examples, and a mean to select which of the examples must be run, as proposed by Sebb. The examples can not be added to the main code as there is an additional dependency (xchart) that we do not want to add to commons-math in general. It was never intended to ship the examples as part of the CM library. [There are provisions in the "pom.xml" to prevent it (IIUC).] IIUC, Sebb proposed that the source code be moved solely for the purpose that maven would compile it with the default config. I was not talking about packaging. IIUC, with Bernd's proposal, this move is thus not necessary. Neither will work, unless you add the relevant dependencies to the main pom.xml which we certainly do not want. I just wanted to point this out before anybody is doing a change. As long as the CM library have no dependencies, is it a problem that non-packaged (or separately packaged) code does have dependencies? Or is it that it will be more complicated to ensure that there is no such dependencies for CM itself once the "pom" file refers to them? Or is it that really the "pom" file is not allowed to contain such references? The best option would certainly be a multi-module project, with the examples / userguide a separate module, but this would require some changes and a few months ago when we started doing this there was no consensus about it. The original issue was: How do we run the examples? Phil proposed an "ant" script, which I would have happily produced. But then if "maven" can do it (with the suggested changes to the "pom.xml"), it's IMO simpler to not have to run a different program. Right now, you can only run them directly in eclipse by adding a project for them, but we could easily do the same as NET does. The original request is: How do we run the examples? To be more specific: how to run a specific example from the command line? I'm perfectly fine with only modifying the "pom.xml" located in src/userguide Would that work? Do you readily know what needs to be added? Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Maven profile for running the examples?
On Tue, 06 Jan 2015 20:41:26 +0100, Thomas Neidhart wrote: On 01/06/2015 07:28 PM, Gilles wrote: On Tue, 06 Jan 2015 17:49:35 +0100, Thomas Neidhart wrote: On 01/06/2015 12:58 PM, Gilles wrote: On Tue, 06 Jan 2015 08:51:32 +0100, Thomas Neidhart wrote: On 01/05/2015 11:58 PM, Gilles wrote: On Mon, 5 Jan 2015 23:48:43 +0100, Bernd Eckenfels wrote: Am Mon, 05 Jan 2015 23:35:49 +0100 schrieb Gilles : Which docs? I didn't intend to move the "userguide" document; only the Java examples currently under "src/userguide/java" would be moved to "src/main" I wont mention multiple modules (also this might be a case where it makes sense, especially if you want to create a dedicated example jar file with its own set of dependencies and as it might avoid calling ant scripts for it), but I would keep the source separated and rather add an additional source directory (with the buildhelper). org.codehaus.mojo build-helper-maven-plugin initialize add-source src/userguide/java NB: this will produce classes on target/classes so you need to exclude them in the JAR. Thanks. I find it cleaner to keep the examples separated from the "main" code; so if this does the trick, I'd prefer it that way. We'd nevertheless need that separate JAR that contains the examples, and a mean to select which of the examples must be run, as proposed by Sebb. The examples can not be added to the main code as there is an additional dependency (xchart) that we do not want to add to commons-math in general. It was never intended to ship the examples as part of the CM library. [There are provisions in the "pom.xml" to prevent it (IIUC).] IIUC, Sebb proposed that the source code be moved solely for the purpose that maven would compile it with the default config. I was not talking about packaging. IIUC, with Bernd's proposal, this move is thus not necessary. Neither will work, unless you add the relevant dependencies to the main pom.xml which we certainly do not want. I just wanted to point this out before anybody is doing a change. As long as the CM library have no dependencies, is it a problem that non-packaged (or separately packaged) code does have dependencies? Or is it that it will be more complicated to ensure that there is no such dependencies for CM itself once the "pom" file refers to them? Or is it that really the "pom" file is not allowed to contain such references? The userguide has dependencies and in order to compile it as part of the "normal" commons-math codebase, e.g. using mvn compile, these dependencies have to be specified in the pom.xml. Afaik the only way to exclude these dependencies would be to use the scope "provided", but it is certainly a solution I would not suggest as it wrongly implies that commons-math has a reference to them, while in fact it hasn't, only the userguide part. Normally, you solve this situations by using a multi-module setup, as said below. The best option would certainly be a multi-module project, with the examples / userguide a separate module, but this would require some changes and a few months ago when we started doing this there was no consensus about it. The original issue was: How do we run the examples? Phil proposed an "ant" script, which I would have happily produced. But then if "maven" can do it (with the suggested changes to the "pom.xml"), it's IMO simpler to not have to run a different program. Right now, you can only run them directly in eclipse by adding a project for them, but we could easily do the same as NET does. The original request is: How do we run the examples? To be more specific: how to run a specific example from the command line? I'm perfectly fine with only modifying the "pom.xml" located in src/userguide Would that work? Do you readily know what needs to be added? yes, but as sebb suggested, the easiest solution is certainly as follows: * create a commons-math-userguide.jar package using mvn package Thus, copying the relevant from the "main" pom (that creates the "tools" JAR) over to the pom in the userguide directory? * copy this jar together with necessary dependencies (xchart, commons-math) into a directory * run java -cp . ExampleXXX parameters That would be good enough, I guess. The whole thing could be further simplified by creating a userguide jar that already contains all dependencies in one jar. There could even be scripts in the userguide that can be executed by a user for this purpose. That's what I meant, if "maven" can be considered as a script. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Math] Next release: 4.0 or 3.5 ?
Hi. Do we head towards 4.0, starting to implement the dreaded breakings? ;-) Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Next release: 4.0 or 3.5 ?
On Tue, 06 Jan 2015 23:10:33 +0100, Gilles wrote: Hi. Do we head towards 4.0, starting to implement the dreaded breakings? ;-) I meant s/breaking/cleanup/ s/breaking/improvement/ of course. :-) Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Maven profile for running the examples?
[...] I have pushed the change to the userguide. To execute the example you do the following: * go to commons-math folder, type mvn clean install this step is only needed if your local maven repository does not yet contain the latest commons-math snapshot * go to userguide folder (src/userguide), type mvn clean package * now you can run the examples like that: java -cp target/commons-math3-examples-uber-3.5-SNAPSHOT.jar org.apache.commons.math3.userguide.LowDiscrepancyGeneratorComparison Very nice. Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
