> On Dec 28, 2017, at 4:05 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > > Hi Rob, > > one additional point: currently, for Maven itself, instead of adding new > Maven-specific ReleasePhase(s) to the default configuration, or configure > them in > our parent pom (I'm not sure documentation on how to do that is available: I > could not find it), we chose first to create a separate "dist-tool" to check > consistency of what is currently published in misc places and provide some > commands to fix when an inconsistency is found. > > This happens through daily reports done by a Jenkins job [1]: > - distribution area vs Maven Central [2] > - version from Maven site vs Maven Central [3] > > We did not produce any release nor made it really configurable for > conventions > different from Maven ones (like Common's -src & -bin), but at least there is > a > configuration file to define artifacts to check [4]
Interesting. Thanks,. -Rob > > HTH > > Hervé > > > [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/ > > [2] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/ > dist-tool-check-source-release.html > > [3] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/ > dist-tool-check-index-page.html > > [4] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/ > dist-tool.conf.html > > Le mercredi 27 décembre 2017, 23:32:49 CET Rob Tompkins a écrit : >> Stephen, >> >> I can’t thank you enough for your reply. I’ll take your suggestions and >> continue to sandbox around using the maven-release-plugin as a guideline. >> >> All the best and happy holidays, >> -Rob >> >>> On Dec 26, 2017, at 5:27 AM, Stephen Connolly >>> <stephen.alan.conno...@gmail.com> wrote:> >>> On Tue 26 Dec 2017 at 03:10, Rob Tompkins <chtom...@apache.org > <mailto:chtom...@apache.org>> wrote: >>>> Hello all, >>>> >>>> Pardon, maybe this should have gone to your @user list, but why not ping >>>> the dev crew. I’ve been playing around the ideas surrounding our fairly >>>> manual release process for the components in Commons, and I was hoping >>>> for >>>> some insights. >>>> >>>> Scripting the version changes isn’t really that big of a deal for us, and >>>> that I can manage. But, when it comes to publishing our artifacts to the >>>> apache nexus repository, and then separately publishing our -src and -bin >>>> assemblies to the dev dist subversion repository (and consequently >>>> deleting >>>> those artifacts from nexus as they’re “attached” for the purpose of gpg >>>> signing), I feel it a tad cumbersome. >>>> >>>> I’ve fiddled around a little with the idea of detaching the -src and -bin >>>> assemblies after gpg signing with some success, but then I have to delve >>>> into the mechanics of publishing those up to the subversion repository, >>>> and >>>> clearly that problem has already been solved. >>> >>> Is your problem you don’t want those going to Nexus staging but only to >>> dist? Or is it that you want them *also* going to dist. >>> >>> Personally... I see no reason to remove them from going to Nexus staging >>> (in fact I have a background plan to add secondary signing support to >>> staging... i’m Waiting to see the Nexus 3 staging APIs before attempting >>> though. That would mean that the PMC would be able to *add* their GPG >>> signature to the staged artifacts as part of the voting... in which case >>> you’d want to hold off uploading to dist until *after* the vote so you get >>> the full set of signatures) >>> >>> If you want to upload a subset of attached artifacts to dist as part of >>> the >>> release, that seems much more tenable... just a derivative of the >>> scm-publish plugin from what I can see. >>> >>> So I find myself in the space of trying to shoehorn our process into its >>> >>>> the main maven-release-plugin, which I’ve found a tad difficult, versus >>>> writing our own release plugin, which feels like I would be duplicating >>>> tons of code (which I don’t want to do). >>> >>> So the release plugin is really two parts: >>> >>> 1. A toolkit for writing release plugins >>> >>> 2. An example that does the job for the requirements of the Maven TLP and >>> has seemed “sufficient” for a lot of other people. >>> >>> As such, if you have different needs, do not feel bad about having to >>> encode differently... hopefully the toolkit half of the codebase is >>> sufficient for you. >>> >>>> I’m curious if you guys have any thoughts on the matter as I’ve been >>>> playing around in the space for a little while now. >>>> >>>> Cheers and happy holidays from UTC-5, >>>> -Rob >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> <mailto:dev-unsubscr...@maven.apache.org> For additional commands, >>>> e-mail: dev-h...@maven.apache.org <mailto:dev-h...@maven.apache.org> >>>> >>>> -- >>> >>> Sent from my phone > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
