Maybe use creadur as home, it is exactly its goal: https://creadur.apache.org/
Le mar. 4 août 2020 à 00:13, sebb <seb...@gmail.com> a écrit : > On Mon, 3 Aug 2020 at 22:15, Rob Tompkins <chtom...@gmail.com> wrote: > > > > > > > > > On Aug 3, 2020, at 5:14 PM, sebb <seb...@gmail.com> wrote: > > > > > > On Mon, 3 Aug 2020 at 19:43, Rob Tompkins <chtom...@gmail.com> wrote: > > >> > > >> That’s just an example of what I’ve been doing. The question is > whether we move this logic into the release plugin for the sake of > validation. > > > > > > I think it's best to keep any checking scripts entirely separate from > > > the Maven generation process. > > > This reduces the risk of common failure modes. > > > > > > However, the variable names could be generated from the Maven POM. > > Better idea: see below - these are in the email. > > > > > > > > Might we write a separate release validation plugin? > > If it is to be a plugin, it would have to be entirely separate. > The user should not have to download the component in order to check > the component ... > > The main advantage of using Maven is that it is cross-platform and all > developers will have it installed. > The disadvantage is that it is generally awkward and verbose compared > with many scripting languages. > However maybe one could use a Maven scripting language plugin such as > Groovy or Ruby. > > == > > It occurs to me that the VOTE email must contain all the links needed > to check the release, so it would be good to use that as input. > This would also act as a check of the mail, which itself is important > for historical tracking. > > > >>>> On Aug 3, 2020, at 2:19 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > > >>> > > >>> Hi Rob, > > >>> > > >>> I am missing something. Is this something you will provide for each > > >>> component? Or, is this a command that is generated in the VOTE.txt? > > >>> The latter seems more reasonable since there are so many variables. > > >>> > > >>> Note that some components have different component names from their > > >>> artifact IDs: pool vs pool2 where some folders are called > .../commons-pool > > >>> or .../pool but the AID is different like commons-pool2 (same for > Commons > > >>> Lang, DBCP, Configuration, VFS, Collections). > > >>> > > >>> Maybe put a bunch of env vars at the top that people can edit, at > least > > >>> that would remove some of the repetition, unless it's generated. > > >>> > > >>> Gary > > >>> > > >>>> On Mon, Aug 3, 2020 at 1:37 PM Rob Tompkins <chtom...@gmail.com> > wrote: > > >>>> > > >>>> Currently I run the following scripts for signature valitaion: > > >>>> > > >>>> > > >>>> > https://github.com/chtompki/notes/blob/master/commons-release-validation/commons-text-1.7-downloader.sh > > >>>> < > > >>>> > https://github.com/chtompki/notes/blob/master/commons-release-validation/commons-text-1.7-downloader.sh > > >>>>> > > >>>> > > >>>> and > > >>>> > > >>>> > > >>>> > https://github.com/chtompki/notes/blob/master/commons-release-validation/commons-text-1.7-sig-validator.sh > > >>>> < > > >>>> > https://github.com/chtompki/notes/blob/master/commons-release-validation/commons-text-1.7-sig-validator.sh > > >>>>> > > >>>> > > >>>> For the sake of making everything easier for everyone should we put > this > > >>>> in the release-plugin for automated validation? > > >>>> > > >>>> -Rob > > >> > > >> --------------------------------------------------------------------- > > >> 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 > > > > > > > --------------------------------------------------------------------- > > 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 > >
