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