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. > > 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
