[
http://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268300#action_268300
]
Lukas Fryc commented on MRELEASE-627:
-------------------------------------
Hello, any chance to have this patch in 2.2 release?
> Fix multi-repository support in the release plugin and make it work with e.g.
> mercurial subrepositories
> -------------------------------------------------------------------------------------------------------
>
> Key: MRELEASE-627
> URL: http://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 contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
