[
http://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247308#action_247308
]
Henning Schmiedehausen commented on MRELEASE-627:
-------------------------------------------------
In case, you are desperate, those are the settings to successfully run
"release:prepare and release:perform (and release:branch and release:stage) on
a Mercurial subrepo tree where the main repository also contains the project
POM and each project is a subrepo (which should be the most common layout):
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.2-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-api</artifactId>
<version>1.5-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-provider-hg</artifactId>
<version>1.5-SNAPSHOT</version>
</dependency>
</dependencies>
<configuration>
<!-- Push all local changes to the remote repo -->
<pushChanges>true</pushChanges>
<!-- Don't produce specific file lists, commit all changes.
This allows Mercurial to implicitly cross the subrepo
boundaries.
-->
<commitAllChanges>true</commitAllChanges>
<!-- commit the full tree, Mercurial takes care of the
subrepos -->
<commitByProject>false</commitByProject>
<!-- revert the tagging order, so that the main project
gets processed
last. This allows it to pick up the changes in the
subrepos. -->
<revertOrder>true</revertOrder>
<!-- tag by project, because there are multiple
repositories. -->
<tagByProject>true</tagByProject>
<!-- In Mercurial, tags are changes in the subrepos that
need to be recorded
in the main repo. So these changes must be recorded
before tagging. -->
<tagRequiresCommit>true</tagRequiresCommit>
<!-- branch by project, because there are multiple
repositories. -->
<branchByProject>true</branchByProject>
<!-- Mercurial branches do an implicit commit after branch,
so there
is no need to do an additional commit. This requires
that
SCM-587 has been applied to your SCM providers. -->
<branchRequiresCommit>false</branchRequiresCommit>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
Settings for other systems (e.g. git or bzr) should be similar, depending on
whether committing the main repo also touches the sub-repos or not.
> 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: 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
