[ https://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290192#comment-290192 ]
Dan Carleton commented on MRELEASE-627: --------------------------------------- For anyone else that lands here, I ended up applying these patches to r1048879 of http://svn.apache.org/repos/asf/maven/release/trunk, and at least got a functioning release:prepare on a multi-module project where the children were in separate Git repositories. The release:perform goal fails while seemingly trying check out from the tags and do a build, but I was able to hobble together my own simulation of it by setting "-DpreparationGoals=clean verify deploy" and manually committing and pushing the commits with the tags. Still a little kludgy but works OK. > Fix multi-repository support in the release plugin and make it work with e.g. > mercurial subrepositories > ------------------------------------------------------------------------------------------------------- > > Key: MRELEASE-627 > URL: https://jira.codehaus.org/browse/MRELEASE-627 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Affects Versions: 2.2 > Reporter: Henning Schmiedehausen > Attachments: MRELEASE-627-2, release-plugin-patch > > > The maven-release-plugin is pretty much designed to work with a single > repository and tag and branch from this. As soon as a project tree is more > complex and e.g. uses nested or multiple repositories (such as the Mercurial > subrepos), it fails. > The attached patch fixes most of the use cases that allow releasing large > (reactor) projects that span multiple projects and use one repository per > project. > New properties: > revertOrder (boolean) - Default: false > Reverts the order in which commit, tag and branch process multi-repos. E.g. > in Mercurial, the main repository (which contains the subrepos) must be > processed last, because it implicitly records state of the relationship > between the main and the sub repository. If it gets committed first, then > this state is not recorded correctly. By reverting the order, the main > repository is committed last. > commitAllChanges (boolean) - Default: false > The release plugin tries to explicitly list which files it commits. However, > in the case of a multi-repository tree, in then tries e.g. to commit > repo/pom.xml, repo/a/pom.xml and repo/b/pom.xml in the context of "repo" > which then fails (because repo/a/pom.xml and repo/b/pom.xml are actually part > of the subrepos a and b). Setting this parameters omits the list of files and > tells the SCM to "commit everything". E.g. Mercurial then picks up the > changes correctly and also records the implicit state between master and sub > repositories correctly. > tagByProject, branchByProject (boolean) - Default: false > Similar to the existing 'commitByProject', these options select whether a tag > or a branch should be created by running the tag command in the root of the > tree or by looping through all projects and tagging or branching them > one-by-one. Default is to tag in the root. > tagRequiresCommit / branchRequiresCommit (boolean) - Default: false > Mercurial manages tags by adding entries to the '.hgtags' file, which is > managed implicitly by the SCM. If a subrepository gets tagged as part of a > larger, multi-repo project, then the changes must be explicitly committed, > else they don't get picked up by the main repository. This sounds more > complicated than it actually is, the summary is that "this must be 'true' for > Mercurial and probably "false" for everything else. > Those changes *should* work with the 1.4 SCM provider, but were tested only > with the 1.5-SNAPSHOT release. It also benefits from fixing the pushChanges > support in the Mercurial provider. > If you want to test drive this patch, you should also be interested in > SCM-587. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira