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
