You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Henning Schmiedehausen (JIRA)" <ji...@codehaus.org> on 2010/12/12 05:03:57 UTC
[jira] Created: (MRELEASE-627) Fix multi-repository support in the
release plugin and make it work with e.g. mercurial subrepositories
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
[jira] Issue Comment Edited: (MRELEASE-627) Fix multi-repository
support in the release plugin and make it work with e.g. mercurial
subrepositories
Posted by "Henning Schmiedehausen (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247308#action_247308 ]
Henning Schmiedehausen edited comment on MRELEASE-627 at 12/11/10 10:09 PM:
----------------------------------------------------------------------------
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):
{code}
<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>
{code}
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.
was (Author: hgschmie):
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
[jira] (MRELEASE-627) Fix multi-repository support in the release
plugin and make it work with e.g. mercurial subrepositories
Posted by "Robert Scholte (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=294392#comment-294392 ]
Robert Scholte commented on MRELEASE-627:
-----------------------------------------
This part of the code has been rewritten completely, so it's not possible to apply these patches anymore.
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 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
[jira] (MRELEASE-627) Fix multi-repository support in the release
plugin and make it work with e.g. mercurial subrepositories
Posted by "Adam (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287936#comment-287936 ]
Adam commented on MRELEASE-627:
-------------------------------
+1 . This fix is not a fringe case fix. Subrepo/submodules are becoming the norm with git and hg.
> 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
[jira] (MRELEASE-627) Fix multi-repository support in the release
plugin and make it work with e.g. mercurial subrepositories
Posted by "Dan Carleton (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289584#comment-289584 ]
Dan Carleton commented on MRELEASE-627:
---------------------------------------
Ran into this today. Without this patch I'll resort to some clunky shell scripts I'm afraid.
> 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
[jira] (MRELEASE-627) Fix multi-repository support in the release
plugin and make it work with e.g. mercurial subrepositories
Posted by "Robert Scholte (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Scholte closed MRELEASE-627.
-----------------------------------
Resolution: Incomplete
Assignee: Robert Scholte
> 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
> Assignee: Robert Scholte
> 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
[jira] (MRELEASE-627) Fix multi-repository support in the release
plugin and make it work with e.g. mercurial subrepositories
Posted by "Dan Carleton (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (MRELEASE-627) Fix multi-repository support in
the release plugin and make it work with e.g. mercurial subrepositories
Posted by "Henning Schmiedehausen (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Updated: (MRELEASE-627) Fix multi-repository support in the
release plugin and make it work with e.g. mercurial subrepositories
Posted by "Henning Schmiedehausen (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henning Schmiedehausen updated MRELEASE-627:
--------------------------------------------
Attachment: MRELEASE-627-2
This additional patch fixes a potential NPE when subrepos have no explict SCM tag in their POM. It also fixes an issue where some changes were pushed even if pushChanges was set to false in the base POM.
> 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
[jira] Commented: (MRELEASE-627) Fix multi-repository support in
the release plugin and make it work with e.g. mercurial subrepositories
Posted by "Lukas Fryc (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] (MRELEASE-627) Fix multi-repository support in the release
plugin and make it work with e.g. mercurial subrepositories
Posted by "Henning Schmiedehausen (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290251#comment-290251 ]
Henning Schmiedehausen commented on MRELEASE-627:
-------------------------------------------------
Yeah, I wrote and only ever used this with Mercurial. You might need to tweak the various options a bit.
The fact that this patch, which is fully functional and tested has not been applied after 13 months is pretty disappointing.
> 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