Hello all, I just wanted to let everyone know where I’ve been running lately. I’m writing a new commons component specifically “commons-release-plugin” for the sake of making a maven plugin that adheres to our release process. I’m sandboxing it in my git work area:
https://github.com/chtompki/commons-release-plugin <https://github.com/chtompki/commons-release-plugin> My goal is to get it functional an then bring it up for vote on creating it as a full fledged component (in the same vein as the commons-build-plugin). Currently, I have it declared locally in [text] with: <groupId>org.apache.commons</groupId> <artifactId>commons-release-plugin</artifactId> <version>0.1-SNAPSHOT</version> <configuration> <pubScmStagingUrl>scm:svn:https://dist.apache.org/repos/dist/dev/commons/text</pubScmStagingUrl> </configuration> <executions> <execution> <id>detatch-assemblies</id> <phase>verify</phase> <goals> <goal>detatch-assemblies</goal> </goals> </execution> </executions> </plugin> immediately following this line: https://github.com/apache/commons-text/blob/master/pom.xml#L164 <https://github.com/apache/commons-text/blob/master/pom.xml#L164> in the pom. As it stands now, it detaches the distributions from the deployment to nexus (after gpg signing, and then copies them and the sha1’s and md5’s into a working directory in /target), My plan here is to use the maven-release-plugin as a guideline for how to publish these up to the dist svn repository. I think I’m further going to set up a mojo to do site deployment to somewhere (open to thoughts on where the site should go, maybe the dist svn area in a zip file like what Gary did with the latest [dbcp] release??). Given this is a progress report. I’m open to anyone telling me that I’m wasting my time and pointing me in a new direction. Cheers, -Rob P.S. I haven’t figured out how to write tests for maven plugins, so I have no testing in the project. I’m open to suggestions/help in that department if anyone wants to chip in and help. > 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] > > 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 > >
