On Wed, 19 Dec 2018 15:11:59 +0000, sebb wrote:
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.
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-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
