On Wed, 19 Dec 2018 15:11:59 +0000, sebb wrote:
> On Wed, 19 Dec 2018 at 14:50, Gilles
>> On Wed, 19 Dec 2018 09:48:30 +0000, 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:
>> >> Please confirm whether the fix is "manual".
>> > Not sure what you mean by that.
>> I mean that the release plugin does not regenerate the
>> 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
>> > commons-build plugin.
>> > Someone needs to release 1.10
>> > In the meantime, to use 1.10-SNAPSHOT you can use a command of
>> > form:
>> > $ mvn
>> > Add -Dcommons.release.version=m.n.o to override the pom version
>> > necessary.
>> Thanks; that's what I missed.
>> Just tried and... two problems:
>> 1. The snapshot does not seem to be available from the usual
>> (Should it be generated by Jenkins?); I had to build the
>> and "install" it locally.
> Yes, forgot about that.
>> 2. Running the above results in an error:
>> [ERROR] Failed to execute goal
>> (default-cli) on project commons-rng: Failed to execute:
>> script: generate-xdocs.build.xml [download-page]: Failed to
>> The following error occurred while executing this line:
>> [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
>> > Since the commons build plugin is only used to automate editing
>> > download source file it does not matter whether you use a
>> > 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
> 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
>> some steps became outdated, with some of their replacement not
>> 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
>> process was broken for some components (namely "Commons RNG"),
>> contrary to what you wrote several times, there was no easy way
>> (i.e. downgrading CP) because the component's POM relied on CP
>> 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
>> >> > or a usage issue?
>> > The download plugin is basically a script to automate
>> > 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
> 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
> do more.
>> > Except of course you need ensure the download xml file is
>> > before starting the release.
>> I do not agree; For as long as I've been here, the advice
>> has been: "Run this command [...] to regenerate the download
> 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.
[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).