commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [All][RNG] Fixing the download page
Date Wed, 19 Dec 2018 17:38:45 GMT
On Wed, 19 Dec 2018 at 15:54, Gilles <gilles@harfang.homelinux.org> wrote:
>
> On Wed, 19 Dec 2018 15:11:59 +0000, sebb wrote:
> > On Wed, 19 Dec 2018 at 14:50, Gilles <gilles@harfang.homelinux.org>
> > wrote:
> >>
> >> On Wed, 19 Dec 2018 09:48:30 +0000, sebb wrote:
> >> > On Wed, 19 Dec 2018 at 00:05, Gilles
> >> <gilles@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.
>
> 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).

The need to update the build plugin has been discussed on the dev
list, and the fixes applied.
However the updated plugin has yet to be released.

So a work-round is needed.

> Bug is in the "Commons" procedure where a required tool stopped

The build plugin is entirely optional.
If it does not produce the correct results, then fix the generated
source manually.

> behaving according to requirements (that are enforced on its
> dependents - Cf. rejected announcement).

> >
> > 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.
>
> It is.
>
> >> 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.
>
> I did provide inputs about expectations from the plugin (from
> a user perspective), months ago.  The release of "Commons RNG"
> (v1.1) was delayed by several months so that it could serve as
> a testing ground.
>
> I'm not the one who complained about the release process; as
> I said, the "mini-recipe" for the components for which I was
> the RM worked quite well (because it was "step-by-step").

If the step-by-step recipe no longer works, then that is a separate
issue from the release or build plugins, and should be fixed
independently if required.

> The ML archive contains a discussion about what could perhaps
> work better in a multimodule project.  I don't think there
> was any follow-up on the suggestion, so that I don't know
> whether the current state of the plugin is considered "feature
> complete" despite its not fully working with a modular project.
> Its documentation doesn't mention anything about its assumptions
> in that respect; AFAIK, the current setup (cf. "dist-archive")
> is just a workaround).
>

Again, if the release plugin does not work for you, then don't use it.
Or try and fix it.

> Gilles
>
> >>
> >> 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-owner@apache.org
> >> wrote:
> >> >> >>> Hi! This is the ezmlm program. I'm managing the
> >> >> >>> announce@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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


Mime
View raw message