On Wed, 19 Dec 2018 at 14:50, Gilles <gil...@harfang.homelinux.org> wrote: > > On Wed, 19 Dec 2018 09:48:30 +0000, sebb wrote: > > On Wed, 19 Dec 2018 at 00:05, Gilles <gil...@harfang.homelinux.org> > > 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. You either need to edit the file or run the build plugin to update the download source page. > If/when the Apache policy changes, it should become a priority task to > update <whatever> we rely on to make releases (that should abide by > that policy). > We cannot ask that people who use _recommended_ procedures suddenly do > without. See above - not the case. > 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]). So raise bugs/enhancement requests and/or patches and get it fixed. > > 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 -0000, 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