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
