[Release-plugin][RNG] WIP? (Was: Fixing the download page)

[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