You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles <gi...@harfang.homelinux.org> on 2018/12/13 15:38:38 UTC
[Release-plugin] Auto-generated download page is wrong (Was:
Returned post for announce@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 -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
[Release-plugin][RNG] WIP? (Was: Fixing the download page)
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 19 Dec 2018 17:38:45 +0000, sebb wrote:
> On Wed, 19 Dec 2018 at 15:54, Gilles <gi...@harfang.homelinux.org>
> wrote:
>>
>> On Wed, 19 Dec 2018 15:11:59 +0000, sebb wrote:
>> > On Wed, 19 Dec 2018 at 14:50, Gilles
>> <gi...@harfang.homelinux.org>
>> > wrote:
>> >>
>> >> On Wed, 19 Dec 2018 09:48:30 +0000, sebb wrote:
>> >> > On Wed, 19 Dec 2018 at 00:05, Gilles
>> >> <gi...@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.
It's like saying "javac" is entirely optional because I could
write bytecode by hand...
My point is that is should be totally _required_ to use common
tooling, in order to develop a kind of "déjà vu" across projects.
>> 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.
What was under the control of the component's POM needed
adjustments too.
What I'm talking about here is what changed "under its feet"
(in CP) based on incorrect assumptions (e.g. project is assumed
to not contain modules) or did not change, whereas it should have
(e.g. the SHA1 deprecation).
>> 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.
Talking past what I'm saying:
1. I'm developing a "Commons" component.
2. I'm told to depend on <some> tool in order to build a
release. [Namely, use the "-Prelease" maven profile.]
3. <some> is changed.
4. Build no longer works.
> Or try and fix it.
If I were going to make changes in tools that affect other
components and suddenly their build started to fail, I'm pretty
sure the reaction will not be that _they_ should fix the issue.
As I said, I provided what input I could in response to Rob's
proposal, and the conversation has been dangling (about the
way the plugin should handle a modular maven project).
Fortunately, Rob extended the existing workaround (of having a
spurious (?) "dist-archive" module). I was left with the
impression that it would be a temporary fix (?).
I'm not asking, you or anyone else, to make it easier for _me_.
I'm discussing what happened in order to improve things for
_everyone_.
It's fine if "multimodule" is considered out-of-scope for the
release-plugin, but should it entail that I have to do _more_
work than before? [And we've also heard people claiming (IIUC)
that our release procedure tries to go against "maven" and/or
"git" workflow...]
I can make report with a list of wish requests related to issues
encountered during the release of "Commons RNG" v1.2.
Is that useful?
Regards,
Gilles
>>>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [All][RNG] Fixing the download page
Posted by sebb <se...@gmail.com>.
On Wed, 19 Dec 2018 at 15:54, Gilles <gi...@harfang.homelinux.org> wrote:
>
> On Wed, 19 Dec 2018 15:11:59 +0000, sebb wrote:
> > On Wed, 19 Dec 2018 at 14:50, Gilles <gi...@harfang.homelinux.org>
> > wrote:
> >>
> >> On Wed, 19 Dec 2018 09:48:30 +0000, sebb wrote:
> >> > On Wed, 19 Dec 2018 at 00:05, Gilles
> >> <gi...@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
Re: [All][RNG] Fixing the download page
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 19 Dec 2018 15:11:59 +0000, sebb wrote:
> On Wed, 19 Dec 2018 at 14:50, Gilles <gi...@harfang.homelinux.org>
> wrote:
>>
>> On Wed, 19 Dec 2018 09:48:30 +0000, sebb wrote:
>> > On Wed, 19 Dec 2018 at 00:05, Gilles
>> <gi...@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).
Bug is in the "Commons" procedure where a required tool stopped
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").
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).
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
Re: [All][RNG] Fixing the download page
Posted by sebb <se...@gmail.com>.
On Wed, 19 Dec 2018 at 14:50, Gilles <gi...@harfang.homelinux.org> wrote:
>
> On Wed, 19 Dec 2018 09:48:30 +0000, sebb wrote:
> > On Wed, 19 Dec 2018 at 00:05, Gilles <gi...@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-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
Re: [All][RNG] Fixing the download page
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 19 Dec 2018 09:48:30 +0000, sebb wrote:
> On Wed, 19 Dec 2018 at 00:05, Gilles <gi...@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).
>
> 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 <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.
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 -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
Re: [All][RNG] Fixing the download page (Was: [Release-plugin]
Auto-generated download page is wrong (Was: Returned post for announce@apache.org))
Posted by sebb <se...@gmail.com>.
On Wed, 19 Dec 2018 at 00:05, Gilles <gi...@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.
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.
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.
> 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.
Except of course you need ensure the download xml file is correct
before starting the release.
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[All][RNG] Fixing the download page (Was: [Release-plugin]
Auto-generated download page is wrong (Was: Returned post for
announce@apache.org))
Posted by Gilles <gi...@harfang.homelinux.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 -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
Re: [Release-plugin] Auto-generated download page is wrong (Was:
Returned post for announce@apache.org)
Posted by Gilles <gi...@harfang.homelinux.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 -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