maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte (JIRA)" <>
Subject [jira] (MRELEASE-627) Fix multi-repository support in the release plugin and make it work with e.g. mercurial subrepositories
Date Sat, 17 Mar 2012 11:10:02 GMT


Robert Scholte commented on MRELEASE-627:

This part of the code has been rewritten completely, so it's not possible to apply these patches
Since there are no tests available in these patches it is hard to confirm whether or not this
issue is fixed.
I might have to close this issue as {{incomplete}}.
> Fix multi-repository support in the release plugin and make it work with e.g. mercurial
> -------------------------------------------------------------------------------------------------------
>                 Key: MRELEASE-627
>                 URL:
>             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
> 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:!default.jspa
For more information on JIRA, see:


View raw message