So the alternate strategy (to what I tested 11 hrs ago) would be to change the release plugin so that it can do its work on a sub-directory safely.
cd <root of plugins multi-module checkout/clone> cd maven-changes-plugin mvn release:prepare mvn release:perform We note after the event that the release was* tagged in SCM with something strong like 'maven-changes-plugin-3.0.0'*. We also silently lament that Git doesn't have branch mappings like Perforce. Indeed, just one small aspect of branch mapping - the ability to remove sections of the tree in the branch and* maintain that divergence going forwards*. Of course tags are not branches, but you know what I mean. In Git given it's content based storage, there's no storage downsides from a branch/tag for 'maven-changes-plugin-3.0.0' also containing all other plugins. Well no storage downsides ignoring working copy (the checkout). - Paul On Tue, Jun 27, 2017 at 8:14 PM, Paul Hammant <p...@hammant.org> wrote: > OK, I tried something new. > > *Goal*: all the plugins in one Git repo (less CI jobs to set up - just > one recursive multi-module maven build). > *Constraint*: Plugins must be independently releasable. > > *Test:* Take two modules from the Svn repo and check them in to master > (the rest were deleted - test needs two and a parent pom in master). > > *Repository*: https://github.com/paul-hammant/ph_testplugins > > Of the two modules checked in, maven-changes-plugin is the one I attempted > to release to my com/paulhammant/ group on 'Central. The workflow for the > release of that single module is here https://github.com/paul- > hammant/ph_testplugins/blob/master/CHANGES_PLUGIN_RELEASE_WORKFLOW.md > > *Result of Test:* failed, but in a surprising way and at a very late stage > > During the release:perform stage the maven tried to push to > https://oss.sonatype.org/content/repositories/snapshots > /com/paulhammant/testplugins-ph-chgs-pi/3.0.0-SNAPSHOT/ > testplugins-ph-chgs-pi-3.0.0-20170627.234743-1.jar which is nuts because > I'm not trying to push to a SNAPSHOT, I'm trying to do a proper release of > 3.0.0 (of my renamed to an obscure name plugin). > > The documentation for the <scm> part of the pom says that it honors the > name of the local branch for the sequence of commits that the release > plugin does. Which is exactly what you'd want. I've already tested it a > dozen times and it does the right thing by way of tags too. It's only that > SNAPSHOT weirdness during the upload that ends the experiment, and that's a > fairly late stage piece. My plan was to go onto oss.sonatype.org and > delete it from staging so it would ultimately go nowhere. > > Barring that bug, this would work for all of the Maven plugins in a single > repo, meaning a lot less permutations for CI, albeit with a longer build > per commit. I don't think that last is a big issue for this proposed > repository. > > Any of you could clone the repo I have made, and do the same steps as > CHANGES_PLUGIN_RELEASE_WORKFLOW.md document to get to the same place I > got to (a 401 error from Sonatype's DAV infra). And one of you could tell > me what I did wrong with the setup to encounter that snapshot issue :) > > - Paul > > > > >
