Maven Release Plugin
  1. Maven Release Plugin
  2. MRELEASE-261

release:prepare should support flat directory multi-module projects

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Component/s: prepare
    • Labels:
      None
    • Environment:
      linux / maven2 / svn
    • Patch Submitted:
      Yes
    • Number of attachments :
      10

      Description

      What I mean by flat file structure firstly.

      parent/pom.xml
      module1/pom.xml
      module2/pom.xml
      .
      .
      .
      module15/pom.xml

      the parent references the modules like so

      <modules>
      <module>../module1</module>
      <module>../module2</module>
      .
      .
      .
      <module>../module15</module>
      </modules>

      When i release:prepare only the parent project is tagged the modules projects versions are incremented etc but the modules are not tagged in svn.

      I use this structure as i use eclipse as my IDE.

      I would love to see a fix for the issue marked as closed here http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand each submodule of the projects but it would be so nice to have the release plugin do this for me.

      forgive my english.

      1. flatProject.main.patch
        11 kB
        Moritz Rebbert
      2. flatProject.test.patch
        9 kB
        Moritz Rebbert
      3. maven-release-issue.tar.gz
        2 kB
        Eric Miles
      4. MRELEASE-261.patch
        12 kB
        Maria Odea Ching
      5. MRELEASE-261-with-its.patch
        32 kB
        Maria Odea Ching
      6. MRELEASE-261-with-its-v3.patch
        77 kB
        Maria Odea Ching
      7. PrepareReleaseMojo.patch
        1 kB
        Adam Leggett
      1. odd-tags.png
        24 kB

        Issue Links

          Activity

          Hide
          John Allen added a comment - - edited

          Dear all, we have converted release 3 plugin to work just fine with flat based multi-modules. The fix works for all maven project structures as it simply changes an invalid assumption made in the existing code base:-

          Currently the 'working directory' of the 'execution project' is assumed to be the top 'ancestor' directory for which all projects contained within the reactor will live under. This is obviously incorrect for flat based projects. The fix is simply a case of determining what the directory in the maven module hierarchy is the common owning directory for all the projects with the hierarchy (which for nested projects happens to be of course the same as the execution project's home, or in other words the working directory').

          For instance (please excuse ASCII art)

          
          A typical nested project hierarchy:
          
          D:\TEMP\MYSTUFF <-- HTTP://SVN.ORG/REPOS/MYSTUFF/TRUNK
          |+POM.XML
          |
          |--B
          |  |+POM.XML
          |  |
          |  |--C
          |     |+POM.XML
          | 
          |--D
          |  |+POM.XML
          |
          |--E
             |+POM.XML
          
          The same logical hierarchy but expressed as a flat maven structure:
          
          D:\TEMP\MYSTUFF  <-- HTTP://SVN.ORG/REPOS/MYSTUFF/TRUNK
          |--ROOT
          |       |+POM.XML
          |
          |--B
          |  |
          |  |--B.ROOT
          |  |       |+POM.XML
          |  |
          |  |--C
          |     |+POM.XML
          |
          |--D
          |  |+POM.XML
          |
          |--E
             |+POM.XML
          

          These two are logically equivalent.

          The observation is that tagging, branching, checkout, checkin etc are version controlled based operations and the majority of VCS systems provide a file system based model (not bothering with object based VC systems here).

          So when we want to tag the stuff in MYSTUFF/TRUNK what we really want to do is create something under the TAGS in SVN (say) that has the trunk contents, thus:

          
          A typical nested project hierarchy:
          
          HTTP://SVN.ORG/REPOS/MYSTUFF/TAGS/MYTAG-1.0/
          |+POM.XML
          |
          |--B
          |  |+POM.XML
          |  |
          |  |--C
          |     |+POM.XML
          | 
          |--D
          |  |+POM.XML
          |
          |--E
             |+POM.XML
          
          And for the flat structure we want:
          
          HTTP://SVN.ORG/REPOS/MYSTUFF/TAGS/MYTAG-1.0/
          |--ROOT
          |       |+POM.XML
          |
          |--B
          |  |
          |  |--B.ROOT
          |  |       |+POM.XML
          |  |
          |  |--C
          |     |+POM.XML
          |
          |--D
          |  |+POM.XML
          |
          |--E
             |+POM.XML
          
          

          By going through the module hierarchy and finding the common directory ancestor we are able to perform all the correct SVN operations (CO, CI, TAG, ETC).

          i.e. For the nested structure the common ancestor directory IS the current directory:

          D:\TEMP\MYSTUFF
          |+POM.XML
          |
          |--B
          |  |+POM.XML
          ...
          

          Top common ancestor directory is equal to 'D:\TEMP\MYSTUFF' which happens to be the same as the working directory of the execution project (the top POM.XML).

          The same approach (of working out the common ancestor) works the on a flat structure but identifies that D:\TEMP\MYSTUFF is the common directory and NOT the execution projects' working directory which is in fact D:\TEMP\MYSTUFF\ROOT\

          D:\TEMP\MYSTUFF
          |--ROOT
          |       |+POM.XML
          |
          |--B
          |  |
          |  |--B.ROOT
          |  |       |+POM.XML
          ...
          

          Cool. So now the only problem is in handling the perform operations where the plugin needs no project, simply checks out everything from the tag URL. Checkout works just fine but there is one critical piece of information missing, namely the path into the 'ROOT' project so that the build can start. This extra bit of information is simply added to the ReleaseConfiguration (that is persisted as release.properties). The perform reads this is an makes that the 'working directory' before it calls maven executor and then kicks off the build.

          Note: Maven is full of assumptions regarding the location of modules being 'beneath' the parent project, for instance the default scheme for constructing URLs and SCM URLS has the derived projects taking the parent's URL and tacking its artifactId on the end. For all us flat-project guys you can usually work around these issues through explicit definition of the elements in the child/derived projects.

          Show
          John Allen added a comment - - edited Dear all, we have converted release 3 plugin to work just fine with flat based multi-modules. The fix works for all maven project structures as it simply changes an invalid assumption made in the existing code base:- Currently the 'working directory' of the 'execution project' is assumed to be the top 'ancestor' directory for which all projects contained within the reactor will live under. This is obviously incorrect for flat based projects. The fix is simply a case of determining what the directory in the maven module hierarchy is the common owning directory for all the projects with the hierarchy (which for nested projects happens to be of course the same as the execution project's home, or in other words the working directory'). For instance (please excuse ASCII art) A typical nested project hierarchy: D:\TEMP\MYSTUFF <-- HTTP: //SVN.ORG/REPOS/MYSTUFF/TRUNK |+POM.XML | |--B | |+POM.XML | | | |--C | |+POM.XML | |--D | |+POM.XML | |--E |+POM.XML The same logical hierarchy but expressed as a flat maven structure: D:\TEMP\MYSTUFF <-- HTTP: //SVN.ORG/REPOS/MYSTUFF/TRUNK |--ROOT | |+POM.XML | |--B | | | |--B.ROOT | | |+POM.XML | | | |--C | |+POM.XML | |--D | |+POM.XML | |--E |+POM.XML These two are logically equivalent. The observation is that tagging, branching, checkout, checkin etc are version controlled based operations and the majority of VCS systems provide a file system based model (not bothering with object based VC systems here). So when we want to tag the stuff in MYSTUFF/TRUNK what we really want to do is create something under the TAGS in SVN (say) that has the trunk contents, thus: A typical nested project hierarchy: HTTP: //SVN.ORG/REPOS/MYSTUFF/TAGS/MYTAG-1.0/ |+POM.XML | |--B | |+POM.XML | | | |--C | |+POM.XML | |--D | |+POM.XML | |--E |+POM.XML And for the flat structure we want: HTTP: //SVN.ORG/REPOS/MYSTUFF/TAGS/MYTAG-1.0/ |--ROOT | |+POM.XML | |--B | | | |--B.ROOT | | |+POM.XML | | | |--C | |+POM.XML | |--D | |+POM.XML | |--E |+POM.XML By going through the module hierarchy and finding the common directory ancestor we are able to perform all the correct SVN operations (CO, CI, TAG, ETC). i.e. For the nested structure the common ancestor directory IS the current directory: D:\TEMP\MYSTUFF |+POM.XML | |--B | |+POM.XML ... Top common ancestor directory is equal to 'D:\TEMP\MYSTUFF' which happens to be the same as the working directory of the execution project (the top POM.XML). The same approach (of working out the common ancestor) works the on a flat structure but identifies that D:\TEMP\MYSTUFF is the common directory and NOT the execution projects' working directory which is in fact D:\TEMP\MYSTUFF\ROOT\ D:\TEMP\MYSTUFF |--ROOT | |+POM.XML | |--B | | | |--B.ROOT | | |+POM.XML ... Cool. So now the only problem is in handling the perform operations where the plugin needs no project, simply checks out everything from the tag URL. Checkout works just fine but there is one critical piece of information missing, namely the path into the 'ROOT' project so that the build can start. This extra bit of information is simply added to the ReleaseConfiguration (that is persisted as release.properties). The perform reads this is an makes that the 'working directory' before it calls maven executor and then kicks off the build. Note: Maven is full of assumptions regarding the location of modules being 'beneath' the parent project, for instance the default scheme for constructing URLs and SCM URLS has the derived projects taking the parent's URL and tacking its artifactId on the end. For all us flat-project guys you can usually work around these issues through explicit definition of the elements in the child/derived projects.
          Hide
          Barrett Nuzum added a comment -

          Hi John.

          Thanks for the update.
          In "we have converted", does that mean there is an immediate fix, or rather that we need to wait for a future release?

          Also, we have scenarios where you may have:

          Parent (under cvs:/group/module1)

          • ProjectA (under cvs:/group/module2)
          • ProjectB (under cvs:/anotherGroup/module3)

          Will that work in this scenario?

          Show
          Barrett Nuzum added a comment - Hi John. Thanks for the update. In "we have converted", does that mean there is an immediate fix, or rather that we need to wait for a future release? Also, we have scenarios where you may have: Parent (under cvs:/group/module1) ProjectA (under cvs:/group/module2) ProjectB (under cvs:/anotherGroup/module3) Will that work in this scenario?
          Hide
          John Allen added a comment -

          Well in that case the common directory is '/' which is probably not what you want as all other folders under '/' would be operated on (checked-in, tagged, etc). Our assumption has been that there is some unifying directory that represented the logical base for the modules underneath it.

          We have a similar setup in regards to your master corporate pom project, that can, via a profile, include all our other projects. i.e.

          /corporate-pom/pom.xml
          /project-a/ - lots of submodules etc
          /project-b/ - lots of submodules etc
          etc

          project-a and project-b, etc all have corporate-pom as their parent and, as i've said, corporate-pom can build all the projects (a,b, etc) (via a profile that include <modules><module>../project-a</module> etc </modules>) but one would not want to release the corporate-pom AND all these other projects at the same time. The 'all projects' setting on the corporate-pom is just for building a master site.

          In our setup one releases corporate-pom, project-a , project-b etc separately as they represent completing different projects with their own release cycles etc.

          Re when will it be avilable? Well we've done the analysis but I'm off for 2 days now so I expect we won't get patches submitted until next week.

          Show
          John Allen added a comment - Well in that case the common directory is '/' which is probably not what you want as all other folders under '/' would be operated on (checked-in, tagged, etc). Our assumption has been that there is some unifying directory that represented the logical base for the modules underneath it. We have a similar setup in regards to your master corporate pom project, that can, via a profile, include all our other projects. i.e. /corporate-pom/pom.xml /project-a/ - lots of submodules etc /project-b/ - lots of submodules etc etc project-a and project-b, etc all have corporate-pom as their parent and, as i've said, corporate-pom can build all the projects (a,b, etc) (via a profile that include <modules><module>../project-a</module> etc </modules>) but one would not want to release the corporate-pom AND all these other projects at the same time. The 'all projects' setting on the corporate-pom is just for building a master site. In our setup one releases corporate-pom, project-a , project-b etc separately as they represent completing different projects with their own release cycles etc. Re when will it be avilable? Well we've done the analysis but I'm off for 2 days now so I expect we won't get patches submitted until next week.
          Hide
          paul.whelan@gmail.com added a comment -

          Great Stuff Guys

          I am not in the office to create a release till the end of the month. I have to say I am having problems with many plugins as a result of using the flat file structure (site plugin for one). This is great news for me as it will save me a lot of time as you can imagine if a project has lots of modules it can become a real pain to do things by hand.

          Thanks for your hard work.

          Show
          paul.whelan@gmail.com added a comment - Great Stuff Guys I am not in the office to create a release till the end of the month. I have to say I am having problems with many plugins as a result of using the flat file structure (site plugin for one). This is great news for me as it will save me a lot of time as you can imagine if a project has lots of modules it can become a real pain to do things by hand. Thanks for your hard work.
          Hide
          John Allen added a comment -

          Hi Paul, we have no problems with the site plugin (bar multiple parents being included in the parent menu, see the recently updated MSITE issues) but that is using a site plugin that we've built ourself with a number of patches applied. Specifically though it works for 'flat multimodule' structures.

          Show
          John Allen added a comment - Hi Paul, we have no problems with the site plugin (bar multiple parents being included in the parent menu, see the recently updated MSITE issues) but that is using a site plugin that we've built ourself with a number of patches applied. Specifically though it works for 'flat multimodule' structures.
          Hide
          Henrik Dohlmann added a comment -

          Hi John,

          Any news on the patch? I have browsed the repository, but it doesn't look like any fixes has been applied regarding this issue.

          Show
          Henrik Dohlmann added a comment - Hi John, Any news on the patch? I have browsed the repository, but it doesn't look like any fixes has been applied regarding this issue.
          Hide
          Barrett Nuzum added a comment -

          I got an email from John Allen that signified his team did not make significant progress on modifying the plugin, and has since abandoned the research, using, instead, a plugin to modify eclipse imports.

          I'm looking at the solution he found – http://eclipse-tools.sourceforge.net/projecttransfer/usage.html
          but I don't think it will work for us.

          Paul, have you been able to make any progress?

          Show
          Barrett Nuzum added a comment - I got an email from John Allen that signified his team did not make significant progress on modifying the plugin, and has since abandoned the research, using, instead, a plugin to modify eclipse imports. I'm looking at the solution he found – http://eclipse-tools.sourceforge.net/projecttransfer/usage.html – but I don't think it will work for us. Paul, have you been able to make any progress?
          Hide
          paul.whelan@gmail.com added a comment -

          Nope Sorry I got no where I just put up with the pain.

          Paul

          Show
          paul.whelan@gmail.com added a comment - Nope Sorry I got no where I just put up with the pain. Paul
          Hide
          John Allen added a comment - - edited

          Subclipse plugin for Eclipse can not handle nested projects in Eclipse at all, and from the dialogue on their list, do not intend to. As Subversive provides much better support for nested Subversion structures in Eclipse, and has since become the 'official' (or so I'm informed) Eclipse foundation Subversion plugin, we have moved to using Subversive and find that the Eclipse multi-project import-export plugin works pretty well. Note the impact analysis for the work of changing the release plugin to be more 'directory aware' was pretty good, 3 days would have it cracked I would expect (inc. ITs etc)

          Show
          John Allen added a comment - - edited Subclipse plugin for Eclipse can not handle nested projects in Eclipse at all, and from the dialogue on their list, do not intend to. As Subversive provides much better support for nested Subversion structures in Eclipse, and has since become the 'official' (or so I'm informed) Eclipse foundation Subversion plugin, we have moved to using Subversive and find that the Eclipse multi-project import-export plugin works pretty well. Note the impact analysis for the work of changing the release plugin to be more 'directory aware' was pretty good, 3 days would have it cracked I would expect (inc. ITs etc)
          Hide
          David Delbecq added a comment -

          Hi all,

          making assumption about directory structure and the fact there is a common ancestor is wrong too!

          I have this svn structure

          and the developper desktop structure based on that svn:

          {pre}

          /home/user/dev/project/topModule (=http://server/project/topModule/trunk/)
          + pom.xml
          + Module1 (=http://server/project/Module1/trunk/)
          + pom.xml
          + Module2 (=http://server/project/Module2/trunk/)
          + pom.xml

          {/pre}

          I expect release plugin to read the submodules pom files, and especially the <scm> entries in that poms, that clearly indicate the svn path of each submodule, which should be tagged as this (using 1.1.1 as release version):

          currently, only the first tag is generated, not the submodules tags.

          The idea is that, during release, if plugin encounter a submodule which as a <scm> which is different than that of parent, it should also tag it.

          Show
          David Delbecq added a comment - Hi all, making assumption about directory structure and the fact there is a common ancestor is wrong too! I have this svn structure http://server/project/topModule/trunk/pom.xml http://server/project/Module1/trunk/pom.xml http://server/project/Module2/trunk/pom.xml and the developper desktop structure based on that svn: {pre} /home/user/dev/project/topModule (= http://server/project/topModule/trunk/ ) + pom.xml + Module1 (= http://server/project/Module1/trunk/ ) + pom.xml + Module2 (= http://server/project/Module2/trunk/ ) + pom.xml {/pre} I expect release plugin to read the submodules pom files, and especially the <scm> entries in that poms, that clearly indicate the svn path of each submodule, which should be tagged as this (using 1.1.1 as release version): http://server/project/topModule/tags/1.1.1/pom.xml http://server/project/Module1/tags/1.1.1/pom.xml http://server/project/Module2/tags/1.1.1/pom.xml currently, only the first tag is generated, not the submodules tags. The idea is that, during release, if plugin encounter a submodule which as a <scm> which is different than that of parent, it should also tag it.
          Hide
          Adam Leggett added a comment - - edited

          Attaching a prospective workaround patch for this issue.

          Patch adds a new configuration property 'tagWorkingDirectory' to Prepare mojo. Then in your relative parent pom you can configure like this:

          <plugin>
                       <groupId>org.apache.maven.plugins</groupId>
                      <artifactId>maven-release-plugin</artifactId>
                       <version>2.0-beta-7-PATCHED</version>
                       <configuration>
                                      <tagWorkingDirectory>${basedir}/..</tagWorkingDirectory>
                                      <preparationGoals>
                                                  clean verify -f ${artifactId}/pom.xml
                                       </preparationGoals>
                                       <connectionUrl>scm:svn:svn://localhost/svn/relative-parent/tags/${artifactId}-${release.version}</connectionUrl>
                                       <goals>clean deploy</goals>
                                       <pomFileName>${artifactId}/pom.xml</pomFileName>
                                      <arguments>-f ${artifactId}/pom.xml</arguments>
                         </configuration>
          </plugin>
          

          The additional config is to ensure the parent pom gets found for the forked lifecycles in release:prepare and release:perform. In addition, due to the release manager now putting the release descriptor (release.properties) in $[basedir}/.. you need to specify the connectionUrl for release:perform. I guess you could write some script to move it or, as above, fill in the url apart from the release version e.g.

          #hello-world/hello-world-parent> mvn release:prepare release:perform -Drelease.version=1.7 --batch-mode
          

          Hope this is useful.

          Adam

          Show
          Adam Leggett added a comment - - edited Attaching a prospective workaround patch for this issue. Patch adds a new configuration property 'tagWorkingDirectory' to Prepare mojo. Then in your relative parent pom you can configure like this: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <version>2.0-beta-7-PATCHED</version> <configuration> <tagWorkingDirectory>${basedir}/..</tagWorkingDirectory> <preparationGoals> clean verify -f ${artifactId}/pom.xml </preparationGoals> <connectionUrl>scm:svn:svn://localhost/svn/relative-parent/tags/${artifactId}-${release.version}</connectionUrl> <goals>clean deploy</goals> <pomFileName>${artifactId}/pom.xml</pomFileName> <arguments>-f ${artifactId}/pom.xml</arguments> </configuration> </plugin> The additional config is to ensure the parent pom gets found for the forked lifecycles in release:prepare and release:perform. In addition, due to the release manager now putting the release descriptor (release.properties) in $[basedir}/.. you need to specify the connectionUrl for release:perform. I guess you could write some script to move it or, as above, fill in the url apart from the release version e.g. #hello-world/hello-world-parent> mvn release:prepare release:perform -Drelease.version=1.7 --batch-mode Hope this is useful. Adam
          Hide
          Robin Custers added a comment -

          does the 2.0-beta-8-SNAPSHOT version already includes this fix? If not how can i use the patched version?

          I tried apply your workaround to the 2.0-beta-8-SNAPSHOT but got the following error:

          [INFO] ----------------------------------------------------------------------------
          [INFO] Building Maven Default Project
          [INFO] task-segment: [clean, verify]
          [INFO] ----------------------------------------------------------------------------
          [INFO] ------------------------------------------------------------------------
          [ERROR] BUILD ERROR
          [INFO] ------------------------------------------------------------------------
          [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one.
          [INFO] ------------------------------------------------------------------------
          [INFO] For more information, run Maven with the -e switch
          [INFO] ------------------------------------------------------------------------
          [INFO] Total time: < 1 second
          [INFO] Finished at: Thu May 22 17:04:49 CEST 2008
          [INFO] Final Memory: 1M/3M
          [INFO] ------------------------------------------------------------------------
          [INFO] --------------------------------------------------------------------

          Tnx

          • Robin
          Show
          Robin Custers added a comment - does the 2.0-beta-8-SNAPSHOT version already includes this fix? If not how can i use the patched version? I tried apply your workaround to the 2.0-beta-8-SNAPSHOT but got the following error: [INFO] ---------------------------------------------------------------------------- [INFO] Building Maven Default Project [INFO] task-segment: [clean, verify] [INFO] ---------------------------------------------------------------------------- [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one. [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: < 1 second [INFO] Finished at: Thu May 22 17:04:49 CEST 2008 [INFO] Final Memory: 1M/3M [INFO] ------------------------------------------------------------------------ [INFO] -------------------------------------------------------------------- Tnx Robin
          Hide
          Neil T Olson added a comment -

          Here's what we did for a workaround:

          In the example above, I would have created a POM.XML in the D:\TEMP\MYSTUFF directory with one sub module, ROOT\POM.XML. No projects refer to it as a parent. It is only a way to identify which sub-module is the "real" root.

          When doing our development in eclipse, we don't have that new POM.XML available. It only shows up when we checkout the whole project. We then run the Manven release:branch and release:prepare mojos from that directory, and everything seems to work fine.

          Example:

          proj\+pom.xml (sub module: base)
                  |
                  |--base
                  |    |+pom.xml (sub modules: ../client, ../server)
                  |
                  |--client
                  |    |+pom.xml (parent: ../base)
                  |
                  |--server
                       |+pom.xml (parent: ../base)
          

          All maven release stuff is done from the proj directory, but all of the eclipse projects are at their specific project level.

          If a fix is done for this, I would love to help out with the testing. We have a relatively complicated configuration (3 levels of hierarchy) that I could test against.
          Thanks - Neil

          Show
          Neil T Olson added a comment - Here's what we did for a workaround: In the example above, I would have created a POM.XML in the D:\TEMP\MYSTUFF directory with one sub module, ROOT\POM.XML. No projects refer to it as a parent. It is only a way to identify which sub-module is the "real" root. When doing our development in eclipse, we don't have that new POM.XML available. It only shows up when we checkout the whole project. We then run the Manven release:branch and release:prepare mojos from that directory, and everything seems to work fine. Example: proj\+pom.xml (sub module: base) | |--base | |+pom.xml (sub modules: ../client, ../server) | |--client | |+pom.xml (parent: ../base) | |--server |+pom.xml (parent: ../base) All maven release stuff is done from the proj directory, but all of the eclipse projects are at their specific project level. If a fix is done for this, I would love to help out with the testing. We have a relatively complicated configuration (3 levels of hierarchy) that I could test against. Thanks - Neil
          Hide
          Sébastien Moreno added a comment -

          Yes it's work fine,
          and it's not a bad concept to have a "build" pom and a "parent" separated.

          In our case, the "root" pom is a child of the "parent" in order to benefit the release change version system and retrieving SCM information.

          The only bad news is that the generated site mention the "root" module as a real separated module.
          But it could be used as a kind of information build summary page.

          Show
          Sébastien Moreno added a comment - Yes it's work fine, and it's not a bad concept to have a "build" pom and a "parent" separated. In our case, the "root" pom is a child of the "parent" in order to benefit the release change version system and retrieving SCM information. The only bad news is that the generated site mention the "root" module as a real separated module. But it could be used as a kind of information build summary page.
          Hide
          David J. M. Karlsen added a comment -

          Any news on this. Not being able to release a flat structure is a real PITA - and having nearly empty pom.xml's around just to satisfy maven is really bad publicity...

          Show
          David J. M. Karlsen added a comment - Any news on this. Not being able to release a flat structure is a real PITA - and having nearly empty pom.xml's around just to satisfy maven is really bad publicity...
          Hide
          Moritz Rebbert added a comment - - edited

          We also using a "flat" hierarchy for some of our projects.

          Based on the assumption of a common ancestor directory that has to be tagged, we started to make a patch.
          It workes for us in a simple setup with a parent project in the same folder with some direct modules. Also it should not destroy the behavior in hierarchical layouts.

          We do not set or change the workingDirectory variable but compute the common ancestor of all projects where we need it. So we technically devided the location where the pom of the root project resides from the directory which will be tagged(or may be branched).

          All projects are tagged under a common directory and "release:perform" also do the job for us.

          I've you are brave, you could give "flatProject.main.patch" a try.
          We also tried to fix the tests in a reasonable way(flatProject.test.patch).

          (We also assume that the layout of the working copy matches the layout in a single repository.)

          Edit: its based on 2.0-beta-9-SNAPSHOT (Last Changed Rev: 726974)

          Show
          Moritz Rebbert added a comment - - edited We also using a "flat" hierarchy for some of our projects. Based on the assumption of a common ancestor directory that has to be tagged, we started to make a patch. It workes for us in a simple setup with a parent project in the same folder with some direct modules. Also it should not destroy the behavior in hierarchical layouts. We do not set or change the workingDirectory variable but compute the common ancestor of all projects where we need it. So we technically devided the location where the pom of the root project resides from the directory which will be tagged(or may be branched). All projects are tagged under a common directory and "release:perform" also do the job for us. I've you are brave, you could give "flatProject.main.patch" a try. We also tried to fix the tests in a reasonable way(flatProject.test.patch). (We also assume that the layout of the working copy matches the layout in a single repository.) Edit: its based on 2.0-beta-9-SNAPSHOT (Last Changed Rev: 726974)
          Hide
          Abel Muiño added a comment -

          I see there are several patches attached to this issue.
          What's the current status? Have any of patches been reviewed/tested? Is there something else that non-committers can provide to help in fixing the issue?

          Show
          Abel Muiño added a comment - I see there are several patches attached to this issue. What's the current status? Have any of patches been reviewed/tested? Is there something else that non-committers can provide to help in fixing the issue?
          Hide
          Maria Odea Ching added a comment -

          I'm currently working on fixing flat multi-module issues with Continuum and I'd probably be touching this issue since Continuum and the maven-release-plugin use the same release manager component. I'll take a look at the attached patches when I get to fixing the releasing part of flat multi-modules.

          See comments in CONTINUUM-1569 for details on how we're approaching this in Continuum..

          Show
          Maria Odea Ching added a comment - I'm currently working on fixing flat multi-module issues with Continuum and I'd probably be touching this issue since Continuum and the maven-release-plugin use the same release manager component. I'll take a look at the attached patches when I get to fixing the releasing part of flat multi-modules. See comments in CONTINUUM-1569 for details on how we're approaching this in Continuum..
          Hide
          Stan Devitt added a comment -

          A workaround that I have used successfully in the past has been:

          1. Organize the modules and parent in a flat pattern with <module>../module1</module> etc. in the parent.
          2. Add an aggregator pom with one module - the parent. - one level up in the file tree.

          Eclipse can ignore the aggregator as it is not referenced by any pom.
          The release plugin can release from the aggregator.

          Show
          Stan Devitt added a comment - A workaround that I have used successfully in the past has been: 1. Organize the modules and parent in a flat pattern with <module>../module1</module> etc. in the parent. 2. Add an aggregator pom with one module - the parent. - one level up in the file tree. Eclipse can ignore the aggregator as it is not referenced by any pom. The release plugin can release from the aggregator.
          Hide
          Maria Odea Ching added a comment -

          Attaching MRELEASE-261.patch..

          The base working directory and the base scm url is determined based on the root project's working dir and scm url, and the relative path of it's modules. Tested the fix with Continuum and the maven-release-plugin.

          I'm not very familiar with the source code of the Maven Release component so I would really appreciate it if someone could review the fix before I commit it to trunk. Thanks in advance..

          Show
          Maria Odea Ching added a comment - Attaching MRELEASE-261 .patch.. The base working directory and the base scm url is determined based on the root project's working dir and scm url, and the relative path of it's modules. Tested the fix with Continuum and the maven-release-plugin. I'm not very familiar with the source code of the Maven Release component so I would really appreciate it if someone could review the fix before I commit it to trunk. Thanks in advance..
          Hide
          Olivier Lamy added a comment -

          Any chance you create an it test for that ?

          Show
          Olivier Lamy added a comment - Any chance you create an it test for that ?
          Hide
          Maria Odea Ching added a comment - - edited

          I only have unit tests for getting the base working dir and base scm url. I just saw the it tests in maven-release-plugin now, I'll see if I can write one for a flat multi-module.

          Show
          Maria Odea Ching added a comment - - edited I only have unit tests for getting the base working dir and base scm url. I just saw the it tests in maven-release-plugin now, I'll see if I can write one for a flat multi-module.
          Hide
          Maria Odea Ching added a comment -

          Attaching revised patch with integration tests for a flat multi-module project and a regular multi-module project.

          Show
          Maria Odea Ching added a comment - Attaching revised patch with integration tests for a flat multi-module project and a regular multi-module project.
          Hide
          Olivier Lamy added a comment -

          I can't find particular issue (only tested with svn) .
          So +1 to commit this.

          Show
          Olivier Lamy added a comment - I can't find particular issue (only tested with svn) . So +1 to commit this.
          Hide
          Maria Odea Ching added a comment -

          Attached patch with a couple of fixes for the tag url written in the pom and additional tests.

          Show
          Maria Odea Ching added a comment - Attached patch with a couple of fixes for the tag url written in the pom and additional tests.
          Hide
          Maria Odea Ching added a comment -

          If no one objects to the fix I did, I'll commit it to trunk already..

          Show
          Maria Odea Ching added a comment - If no one objects to the fix I did, I'll commit it to trunk already..
          Hide
          Maria Odea Ching added a comment -

          Fixed in trunk 778088 (applied MRELEASE-261-with-its-v3.patch).

          Show
          Maria Odea Ching added a comment - Fixed in trunk 778088 (applied MRELEASE-261 -with-its-v3.patch).
          Hide
          Maria Odea Ching added a comment -

          Additional fix for determining the common path which was failing in windows was committed to trunk -r778269.

          Show
          Maria Odea Ching added a comment - Additional fix for determining the common path which was failing in windows was committed to trunk -r778269.
          Hide
          Eric Miles added a comment -

          Sample project that still has release issues in a flat structure

          Show
          Eric Miles added a comment - Sample project that still has release issues in a flat structure
          Hide
          Eric Miles added a comment - - edited

          I'm not 100% sure this is fixed. I setup a project to use the beta-10-SNAPSHOT plugin and it is still not working, I'm getting the following error while trying to prepare the release:

          [INFO] [INFO] ------------------------------------------------------------------------
          [INFO] Checking in modified POMs...
          [INFO] Executing: /bin/sh -c cd /Users/emiles/Projects/release-workspace/release-parent && svn --non-interactive commit --file /var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-1253932520.commit --targets /var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-4376558781490229966-targets
          [INFO] Working directory: /Users/emiles/Projects/release-workspace/release-parent
          [INFO] ------------------------------------------------------------------------
          [ERROR] BUILD FAILURE
          [INFO] ------------------------------------------------------------------------
          [INFO] Unable to commit files
          Provider message:
          The svn command failed.
          Command output:
          svn: '/Users/emiles/Projects/release-workspace' is not a working copy
          

          I have confirmed that I am using the beta 10 release as well as I have confirmed the beta 10 release in Apache snapshots contained the v3.patch identified in one of the previous comments. I'm attaching my sample project, maven-release-issue.tar.gz. I'm hoping this can be used as a test case and/or someone can tell me if I've set the project up incorrectly.

          This work is being performed in a Mac OS X environment with JDK 1.5 and SVN 1.6.6.

          An update...I have completely removed the release plugin and am only using the svn binary on my box. I still get the same issue, issuing a similar command

          emiles-macbook:~ emiles$ svn --non-interactive commit --file /tmp/svn-msg --targets /tmp/targets 
          svn: '/Users/emiles/Projects/release-workspace' is not a working copy
          

          Here's a cat of svn-msg:

          emiles-macbook:~ emiles$ cat /tmp/svn-msg 
          [maven-release-plugin] prepare release release-parent-0.0.1emiles-macbook:~ emiles$ 
          

          And a cat of targets:

          emiles$ cat /tmp/targets
          /Users/emiles/Projects/release-workspace/release-parent/pom.xml
          /Users/emiles/Projects/release-workspace/release-module1/pom.xml
          /Users/emiles/Projects/release-workspace/release-module2/pom.xml
          

          So that this point, I'm beginning to wonder if it's the svn binary causing an issue, at this point we have completely circumvented the release plugin. Or maybe it's the way the release plugin is attempting to use SVN?

          Show
          Eric Miles added a comment - - edited I'm not 100% sure this is fixed. I setup a project to use the beta-10-SNAPSHOT plugin and it is still not working, I'm getting the following error while trying to prepare the release: [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Checking in modified POMs... [INFO] Executing: /bin/sh -c cd /Users/emiles/Projects/release-workspace/release-parent && svn --non-interactive commit --file / var /folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-1253932520.commit --targets / var /folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-4376558781490229966-targets [INFO] Working directory: /Users/emiles/Projects/release-workspace/release-parent [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Unable to commit files Provider message: The svn command failed. Command output: svn: '/Users/emiles/Projects/release-workspace' is not a working copy I have confirmed that I am using the beta 10 release as well as I have confirmed the beta 10 release in Apache snapshots contained the v3.patch identified in one of the previous comments. I'm attaching my sample project, maven-release-issue.tar.gz. I'm hoping this can be used as a test case and/or someone can tell me if I've set the project up incorrectly. This work is being performed in a Mac OS X environment with JDK 1.5 and SVN 1.6.6. An update...I have completely removed the release plugin and am only using the svn binary on my box. I still get the same issue, issuing a similar command emiles-macbook:~ emiles$ svn --non-interactive commit --file /tmp/svn-msg --targets /tmp/targets svn: '/Users/emiles/Projects/release-workspace' is not a working copy Here's a cat of svn-msg: emiles-macbook:~ emiles$ cat /tmp/svn-msg [maven-release-plugin] prepare release release-parent-0.0.1emiles-macbook:~ emiles$ And a cat of targets: emiles$ cat /tmp/targets /Users/emiles/Projects/release-workspace/release-parent/pom.xml /Users/emiles/Projects/release-workspace/release-module1/pom.xml /Users/emiles/Projects/release-workspace/release-module2/pom.xml So that this point, I'm beginning to wonder if it's the svn binary causing an issue, at this point we have completely circumvented the release plugin. Or maybe it's the way the release plugin is attempting to use SVN?
          Hide
          Maria Odea Ching added a comment -

          Re-opened issue due to last comment.

          Show
          Maria Odea Ching added a comment - Re-opened issue due to last comment.
          Hide
          Dennis Lundberg added a comment -

          Eric,

          I tried to have a look at the sample project you supplied, but all I find in the archive is something that looks like a file for Eclipse.
          Do you have a Maven project that can be used to reproduce your problems?

          Show
          Dennis Lundberg added a comment - Eric, I tried to have a look at the sample project you supplied, but all I find in the archive is something that looks like a file for Eclipse. Do you have a Maven project that can be used to reproduce your problems?
          Hide
          Eric Miles added a comment -

          The file I've attached has 3 subdirectories, each with a pom in it. I have re-downloaded the archive attached to this JIRA and it works fine. It is in tar.gz format, make sure you are downloading the maven-release-issue.tar.gz file.

          Show
          Eric Miles added a comment - The file I've attached has 3 subdirectories, each with a pom in it. I have re-downloaded the archive attached to this JIRA and it works fine. It is in tar.gz format, make sure you are downloading the maven-release-issue.tar.gz file.
          Hide
          Dennis Lundberg added a comment -

          Re-uploading Eric's sample project, this time in regular zip-format without any Eclipse files. The .tar.gz file has a strange format that can't be extracted using 7-zip on Windows. Even the Archive Manager on Ubuntu didn't like it.

          Show
          Dennis Lundberg added a comment - Re-uploading Eric's sample project, this time in regular zip-format without any Eclipse files. The .tar.gz file has a strange format that can't be extracted using 7-zip on Windows. Even the Archive Manager on Ubuntu didn't like it.
          Hide
          Dennis Lundberg added a comment -

          Eric, are you sure that the contents of '/Users/emiles/Projects/release-workspace' really is a Subversion working copy?

          What does this command tell you?

          ls -la /Users/emiles/Projects/release-workspace
          
          Show
          Dennis Lundberg added a comment - Eric, are you sure that the contents of '/Users/emiles/Projects/release-workspace' really is a Subversion working copy? What does this command tell you? ls -la /Users/emiles/Projects/release-workspace
          Hide
          Eric Miles added a comment - - edited

          Dennis,

          I know this isn't a working directory. This is the eclipse workspace folder that contains the three projects and is the parent directory to the parent pom project. Here is my directory structure:

          release-workspace\
                  |
                  |--release-parent
                  |    |+pom.xml (modules: ../release-module1, ../release-module2)
                  |
                  |--release-module1
                  |    |+pom.xml (parent: ../release-parent)
                  |
                  |--release-module2
                       |+pom.xml (parent: ../release-parent)
          

          I am issuing the release:prepare from the release-parent directory, so there should be no reason I receive this error.

          I have asked a coworker on a Windows box to pull down the sample project attachment, he had no problems opening it with 7zip. In any case, I'm attaching another sample project archived in a zip format. Please see http://jira.codehaus.org/secure/attachment/46726/maven-release-issue.zip
          .

          Show
          Eric Miles added a comment - - edited Dennis, I know this isn't a working directory. This is the eclipse workspace folder that contains the three projects and is the parent directory to the parent pom project. Here is my directory structure: release-workspace\ | |--release-parent | |+pom.xml (modules: ../release-module1, ../release-module2) | |--release-module1 | |+pom.xml (parent: ../release-parent) | |--release-module2 |+pom.xml (parent: ../release-parent) I am issuing the release:prepare from the release-parent directory, so there should be no reason I receive this error. I have asked a coworker on a Windows box to pull down the sample project attachment, he had no problems opening it with 7zip. In any case, I'm attaching another sample project archived in a zip format. Please see http://jira.codehaus.org/secure/attachment/46726/maven-release-issue.zip .
          Hide
          Eric Miles added a comment -

          A zip archive of the sample project I have provided

          Show
          Eric Miles added a comment - A zip archive of the sample project I have provided
          Hide
          Dennis Lundberg added a comment -

          Eric,

          Are you saying that Subversion is complaining about the status of '/Users/emiles/Projects/release-workspace' which is a folder that is not under svn control, that only contains three folders that are themselves checked out from Subversion?

          Show
          Dennis Lundberg added a comment - Eric, Are you saying that Subversion is complaining about the status of '/Users/emiles/Projects/release-workspace' which is a folder that is not under svn control, that only contains three folders that are themselves checked out from Subversion?
          Hide
          Eric Miles added a comment -

          Dennis,

          That is correct. The only operation performed is the release:prepare from within an SVN managed folder (the parent POM project folder), which happens to be a sub-folder of the folder SVN is complaining about..

          Show
          Eric Miles added a comment - Dennis, That is correct. The only operation performed is the release:prepare from within an SVN managed folder (the parent POM project folder), which happens to be a sub-folder of the folder SVN is complaining about..
          Hide
          Dennis Lundberg added a comment -

          OK then, I've looked through the code where things are breaking down.

          Could you please try this at your end:

          mvn release:prepare -DcommitByProject=true
          
          Show
          Dennis Lundberg added a comment - OK then, I've looked through the code where things are breaking down. Could you please try this at your end: mvn release:prepare -DcommitByProject=true
          Hide
          Eric Miles added a comment -

          Screen shot of the odd tagging performed with the flat project structure

          Show
          Eric Miles added a comment - Screen shot of the odd tagging performed with the flat project structure
          Hide
          Eric Miles added a comment - - edited

          Dennis,

          The good news is that the prepare goal SOMEWHAT worked. While it was able to change the POMs and check those in appropriately, however it failed on tagging the release. Instead of having tag for each one of the modules (which is what I would expect), only the parent pom project was tagged and was tagged in an odd way. I'm attaching a screenshot, but the tag contains a branches, tags, and trunk folder underneath the tag. Take a look at the odd-tags.png file I have attached.

          Ignoring the tagging issue, I attempted to perform the release itself. This is the error I received:

          emiles-macbook:release-parent emiles$ mvn release:perform -DcommitByProject=true
          [INFO] Scanning for projects...
          [INFO] Reactor build order: 
          [INFO]   Unnamed - com.captechventures:release-parent:pom:0.0.3-SNAPSHOT
          [INFO]   Unnamed - com.captechventures:release-module1:jar:0.0.3-SNAPSHOT
          [INFO]   Unnamed - com.captechventures:release-module2:jar:0.0.3-SNAPSHOT
          [INFO] ------------------------------------------------------------------------
          [INFO] Building Unnamed - com.captechventures:release-parent:pom:0.0.3-SNAPSHOT
          [INFO]    task-segment: [release:perform] (aggregator-style)
          [INFO] ------------------------------------------------------------------------
          [INFO] [release:perform {execution: default-cli}]
          [INFO] Checking out the project to perform the release ...
          [INFO] Executing: /bin/sh -c cd /Users/emiles/Projects/release-workspace/release-parent/target && svn --non-interactive checkout http://localhost/dev/release-parent/tags/release-parent-0.0.2 /Users/emiles/Projects/release-workspace/release-parent/target/checkout
          [INFO] Working directory: /Users/emiles/Projects/release-workspace/release-parent/target
          [INFO] Executing goals 'deploy'...
          [WARNING] Base directory is a file. Using base directory as POM location.
          [WARNING] Maven will be executed in interactive mode, but no input stream has been configured for this MavenInvoker instance.
          [INFO] ------------------------------------------------------------------------
          [ERROR] BUILD ERROR
          [INFO] ------------------------------------------------------------------------
          [INFO] Error executing Maven.
          
          Working directory "/Users/emiles/Projects/release-workspace/release-parent/target/checkout/Users/emiles/Projects/release-workspace/release-parent" does not exist!
          [INFO] ------------------------------------------------------------------------
          [INFO] For more information, run Maven with the -e switch
          [INFO] ------------------------------------------------------------------------
          [INFO] Total time: 5 seconds
          [INFO] Finished at: Mon Jan 04 12:22:31 EST 2010
          [INFO] Final Memory: 11M/20M
          [INFO] ------------------------------------------------------------------------
          
          

          I had a configuration that I followed from one of the test cases checked in, where the workingDirectory was specified in the configuration of the plugin. seen as follows:

          			<plugin>
          				<groupId>org.apache.maven.plugins</groupId>
          				<artifactId>maven-release-plugin</artifactId>
          				<version>2.0-beta-10-20091102.165928-8</version>
          				<configuration>
          					<workingDirectory>${basedir}/target/checkout</workingDirectory>
          					<useReleaseProfile>true</useReleaseProfile>
          					<allowTimestampedSnapshots>true</allowTimestampedSnapshots>
          				</configuration>
          			</plugin>
          

          I thought maybe this was the reason for the error, so I removed the workingDirectory configuration, performed all my checkins, did a prepare and attempted to release again and I received the same error as what is identified as above (I'm assuming this directory is the default config).

          Show
          Eric Miles added a comment - - edited Dennis, The good news is that the prepare goal SOMEWHAT worked. While it was able to change the POMs and check those in appropriately, however it failed on tagging the release. Instead of having tag for each one of the modules (which is what I would expect), only the parent pom project was tagged and was tagged in an odd way. I'm attaching a screenshot, but the tag contains a branches, tags, and trunk folder underneath the tag. Take a look at the odd-tags.png file I have attached. Ignoring the tagging issue, I attempted to perform the release itself. This is the error I received: emiles-macbook:release-parent emiles$ mvn release:perform -DcommitByProject=true [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Unnamed - com.captechventures:release-parent:pom:0.0.3-SNAPSHOT [INFO] Unnamed - com.captechventures:release-module1:jar:0.0.3-SNAPSHOT [INFO] Unnamed - com.captechventures:release-module2:jar:0.0.3-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] Building Unnamed - com.captechventures:release-parent:pom:0.0.3-SNAPSHOT [INFO] task-segment: [release:perform] (aggregator-style) [INFO] ------------------------------------------------------------------------ [INFO] [release:perform {execution: default-cli}] [INFO] Checking out the project to perform the release ... [INFO] Executing: /bin/sh -c cd /Users/emiles/Projects/release-workspace/release-parent/target && svn --non-interactive checkout http://localhost/dev/release-parent/tags/release-parent-0.0.2 /Users/emiles/Projects/release-workspace/release-parent/target/checkout [INFO] Working directory: /Users/emiles/Projects/release-workspace/release-parent/target [INFO] Executing goals 'deploy'... [WARNING] Base directory is a file. Using base directory as POM location. [WARNING] Maven will be executed in interactive mode, but no input stream has been configured for this MavenInvoker instance. [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error executing Maven. Working directory "/Users/emiles/Projects/release-workspace/release-parent/target/checkout/Users/emiles/Projects/release-workspace/release-parent" does not exist! [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 5 seconds [INFO] Finished at: Mon Jan 04 12:22:31 EST 2010 [INFO] Final Memory: 11M/20M [INFO] ------------------------------------------------------------------------ I had a configuration that I followed from one of the test cases checked in, where the workingDirectory was specified in the configuration of the plugin. seen as follows: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <version>2.0-beta-10-20091102.165928-8</version> <configuration> <workingDirectory>${basedir}/target/checkout</workingDirectory> <useReleaseProfile>true</useReleaseProfile> <allowTimestampedSnapshots>true</allowTimestampedSnapshots> </configuration> </plugin> I thought maybe this was the reason for the error, so I removed the workingDirectory configuration, performed all my checkins, did a prepare and attempted to release again and I received the same error as what is identified as above (I'm assuming this directory is the default config).
          Hide
          Dennis Lundberg added a comment -

          Eric,

          I've been playing around with your example on my virtual Ubuntu to try to reproduce your problems.

          I'm having problems understanding what the directory structure in SVN looks like for your example.
          Can you please describe it for us?

          Here's what I think, based on the POMs.

          +--release-parent/trunk/pom.xml
          |
          +--release-module1/trunk/pom.xml
          |
          +--release-module1/trunk/pom.xml
          

          Is that correct?

          Is that how multi module projects with a flat structure are usually stored in SVN?

          Show
          Dennis Lundberg added a comment - Eric, I've been playing around with your example on my virtual Ubuntu to try to reproduce your problems. I'm having problems understanding what the directory structure in SVN looks like for your example. Can you please describe it for us? Here's what I think, based on the POMs. +--release-parent/trunk/pom.xml | +--release-module1/trunk/pom.xml | +--release-module1/trunk/pom.xml Is that correct? Is that how multi module projects with a flat structure are usually stored in SVN?
          Hide
          Eric Miles added a comment - - edited

          Dennis,

          Yes, you are correct in that's the structure. I'm not sure how "flat" multi-module projects are usually stored in SVN, however, I'm a consultant and have been on 3 different clients/projects i the last 2 years and all 3 of these clients had their subversion repo setup this way (were setup LONG before I got there).

          Regardless, I would think the release plugin would work appropriately no matter what my SVN structure is considering that metadata is provided in the POM. I would think it shouldn't care how it's stored in SVN (or any SCM for that matter) nor should it care what structure it is in as long as the parent pom is available (in the reactor or available via relativePath).

          I'm guessing that's a false assumption at this point

          Show
          Eric Miles added a comment - - edited Dennis, Yes, you are correct in that's the structure. I'm not sure how "flat" multi-module projects are usually stored in SVN, however, I'm a consultant and have been on 3 different clients/projects i the last 2 years and all 3 of these clients had their subversion repo setup this way (were setup LONG before I got there). Regardless, I would think the release plugin would work appropriately no matter what my SVN structure is considering that metadata is provided in the POM. I would think it shouldn't care how it's stored in SVN (or any SCM for that matter) nor should it care what structure it is in as long as the parent pom is available (in the reactor or available via relativePath). I'm guessing that's a false assumption at this point
          Hide
          Dennis Lundberg added a comment -

          Eric,

          After more digging in the source code I found an Integration Test for a flat multi module project.
          http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-plugin/src/it/flat-multi-module/

          This project only has an SCM element in the parent project. This is what I was expecting to find. Have a look at it and see if it can help you in any way.

          If you have a multi module project that you want to release all in one go, then that should also be reflected in the SCM, by having a single trunk for the entire multi module project.

          Show
          Dennis Lundberg added a comment - Eric, After more digging in the source code I found an Integration Test for a flat multi module project. http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-plugin/src/it/flat-multi-module/ This project only has an SCM element in the parent project. This is what I was expecting to find. Have a look at it and see if it can help you in any way. If you have a multi module project that you want to release all in one go, then that should also be reflected in the SCM, by having a single trunk for the entire multi module project.
          Hide
          Eric Miles added a comment - - edited

          Dennis,

          So I guess you're saying that it's impossible for the release plugin to support the following SVN structure (or there are no future plans to support it)?

          svnroot
          |
          +--release-parent/trunk/pom.xml
          |
          +--release-module1/trunk/pom.xml
          |
          +--release-module1/trunk/pom.xml
          

          The reason I ask is I am often brought on client/projects LONG after their SVN repos are setup and whether or not they can use the release plugin (especially for large projects) would be a big determinator for me in a Maven recommendation. Trust me, I'd prefer if clients could/would reposition their SVN repo and existing projects so multi-module builds "just worked".

          It sounds like the definition of a flat structure in this particular test case is all projects "flattened" behind a single trunk/branch/tag. My use case are the projects are flattened at the SVN root level, but each have their own trunk/branches/tags. It seems as though my use case is a hybrid of the typical maven setup and the flattened use case you have provided.

          Show
          Eric Miles added a comment - - edited Dennis, So I guess you're saying that it's impossible for the release plugin to support the following SVN structure (or there are no future plans to support it)? svnroot | +--release-parent/trunk/pom.xml | +--release-module1/trunk/pom.xml | +--release-module1/trunk/pom.xml The reason I ask is I am often brought on client/projects LONG after their SVN repos are setup and whether or not they can use the release plugin (especially for large projects) would be a big determinator for me in a Maven recommendation. Trust me, I'd prefer if clients could/would reposition their SVN repo and existing projects so multi-module builds "just worked". It sounds like the definition of a flat structure in this particular test case is all projects "flattened" behind a single trunk/branch/tag. My use case are the projects are flattened at the SVN root level, but each have their own trunk/branches/tags. It seems as though my use case is a hybrid of the typical maven setup and the flattened use case you have provided.
          Hide
          Dennis Lundberg added a comment -

          Thanks for explaining Eric,

          It does seem that the problem you have is slightly different than the one covered by his issue.

          The reason why I'm asking all these questions is that I haven't worked with flat projects before. Because of that I'm not in a position to say if there are any future plans for such a feature.

          Would you mind opening up a new JIRA issue for your problem, so that we don't loose it. I'll link the two issues together.

          One final question, to give me a better understanding of your use case.
          Why do you (or your clients) have branches/tags/trunk for each module, when you (or they) release them all together?

          Show
          Dennis Lundberg added a comment - Thanks for explaining Eric, It does seem that the problem you have is slightly different than the one covered by his issue. The reason why I'm asking all these questions is that I haven't worked with flat projects before. Because of that I'm not in a position to say if there are any future plans for such a feature. Would you mind opening up a new JIRA issue for your problem, so that we don't loose it. I'll link the two issues together. One final question, to give me a better understanding of your use case. Why do you (or your clients) have branches/tags/trunk for each module, when you (or they) release them all together?
          Hide
          Eric Miles added a comment -

          Dennis,

          No problem with the questions. When I get enough time, I'll create a new JIRA and reference here in the comments.

          I wish I could answer why they have setup their repositories this way, I certainly would have steered them otherwise if I had been there during initial infrastructure setup. My current client I'm pushing to move to the more traditional nested model for Maven multi-module projects, but it's not a quick process. One multi-module build of theirs contains over 36 modules (and an obvious candidate for breaking into smaller project)!

          Thanks again for your help.

          Show
          Eric Miles added a comment - Dennis, No problem with the questions. When I get enough time, I'll create a new JIRA and reference here in the comments. I wish I could answer why they have setup their repositories this way, I certainly would have steered them otherwise if I had been there during initial infrastructure setup. My current client I'm pushing to move to the more traditional nested model for Maven multi-module projects, but it's not a quick process. One multi-module build of theirs contains over 36 modules (and an obvious candidate for breaking into smaller project)! Thanks again for your help.
          Hide
          Dennis Lundberg added a comment -

          The reason this was reopened turned out to be a variation on this issue. A new issue will be created for that variation. Closing this one as fixed now.

          Show
          Dennis Lundberg added a comment - The reason this was reopened turned out to be a variation on this issue. A new issue will be created for that variation. Closing this one as fixed now.
          Hide
          Eric Miles added a comment -

          New issue created, and mentioned in the description.

          MRELEASE-516

          Show
          Eric Miles added a comment - New issue created, and mentioned in the description. MRELEASE-516
          Hide
          Brett Porter added a comment -

          this has caused a small issue on tagging with projects that have modules like so:
          <module>sub/module</module>

          I have a test case to reproduce it and will rework the path manipulations to pass that and the additional tests for flat projects.

          Show
          Brett Porter added a comment - this has caused a small issue on tagging with projects that have modules like so: <module>sub/module</module> I have a test case to reproduce it and will rework the path manipulations to pass that and the additional tests for flat projects.
          Hide
          Brett Porter added a comment -

          additional issue fixed and tests added

          Show
          Brett Porter added a comment - additional issue fixed and tests added
          Hide
          Michael Glauche added a comment -

          I still have trouble with multi module builds and cvs, i did create a test-project with one parent and 2 modules and set the maven-release-plugin to 2.0. When i run release:prepare i'm getting the following:

           
          C:\work\workspaces\maven\test-main>mvn release:prepare -Dusername=rt55 -Dresume=false -DcommitByProject=true
          [INFO] Scanning for projects...
          [INFO] Reactor build order:
          [INFO]   Unnamed - test:test-main:pom:0.0.1
          [INFO]   Unnamed - test:modul2:jar:0.0.1-SNAPSHOT
          [INFO]   Unnamed - test:modul1:jar:0.0.1-SNAPSHOT
          [INFO] Searching repository for plugin with prefix: 'release'.
          [INFO] ------------------------------------------------------------------------
          [INFO] Building Unnamed - test:test-main:pom:0.0.1
          [INFO]    task-segment: [release:prepare] (aggregator-style)
          [INFO] ------------------------------------------------------------------------
          [INFO] [release:prepare {execution: default-cli}]
          [INFO] Verifying that there are no local modifications...
          [INFO] Executing: cmd.exe /X /C "cvs -z3 -d :pserver:rt55@cvsserver:/home/cvs/repository/test -n -q update -d"
          [INFO] Working directory: C:\work\workspaces\maven\test-main
          [INFO] Checking dependencies and plugins for snapshots ...
          ...
          [INFO] [INFO] ------------------------------------------------------------------------
          [INFO] [INFO] Reactor Summary:
          [INFO] [INFO] ------------------------------------------------------------------------
          [INFO] [INFO] Unnamed - test:test-main:pom:0.0.1 ...... SUCCESS [3.609s]
          [INFO] [INFO] Unnamed - test:modul2:jar:0.0.1 ......... SUCCESS [1.157s]
          [INFO] [INFO] Unnamed - test:modul1:jar:0.0.1 ......... SUCCESS [0.531s]
          [INFO] [INFO] ------------------------------------------------------------------------
          [INFO] [INFO] ------------------------------------------------------------------------
          [INFO] [INFO] BUILD SUCCESSFUL
          [INFO] [INFO] ------------------------------------------------------------------------
          [INFO] [INFO] Total time: 5 seconds
          [INFO] [INFO] Finished at: Tue Aug 24 14:25:39 CEST 2010
          [INFO] [INFO] Final Memory: 21M/254M
          [INFO] [INFO] ------------------------------------------------------------------------
          [INFO] Checking in modified POMs...
          [INFO] Executing: cmd.exe /X /C "cvs -z3 -q commit -R -F C:\DOCUME~1\rt55\LOCALS~1\Temp\scm-commit-message5089.txt pom.xml"
          [INFO] Working directory: C:\work\workspaces\maven\test-main
          [INFO] Executing: cmd.exe /X /C "cvs -z3 -q commit -R -F C:\DOCUME~1\rt55\LOCALS~1\Temp\scm-commit-message5091.txt pom.xml"
          [INFO] Working directory: C:\work\workspaces\maven\test-module2
          [INFO] Executing: cmd.exe /X /C "cvs -z3 -q commit -R -F C:\DOCUME~1\rt55\LOCALS~1\Temp\scm-commit-message5093.txt pom.xml"
          [INFO] Working directory: C:\work\workspaces\maven\test-module1
          [INFO] Tagging release with the label test-main-0_0_1...
          [INFO] ------------------------------------------------------------------------
          [ERROR] BUILD FAILURE
          [INFO] ------------------------------------------------------------------------
          [INFO] The scm url is invalid.
            - The connection string contains too few tokens.
          

          Now, the changes are correctly checked, so i assume the scm url is correct, or ?

            <scm>
               <connection>scm:cvs|pserver|${maven.scm.username}@cvsserver|/home/cvs/repository/test|maventest_main</connection>
            </scm>
          

          Am I doing something wrong ?

          Show
          Michael Glauche added a comment - I still have trouble with multi module builds and cvs, i did create a test-project with one parent and 2 modules and set the maven-release-plugin to 2.0. When i run release:prepare i'm getting the following: C:\work\workspaces\maven\test-main>mvn release:prepare -Dusername=rt55 -Dresume=false -DcommitByProject=true [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Unnamed - test:test-main:pom:0.0.1 [INFO] Unnamed - test:modul2:jar:0.0.1-SNAPSHOT [INFO] Unnamed - test:modul1:jar:0.0.1-SNAPSHOT [INFO] Searching repository for plugin with prefix: 'release'. [INFO] ------------------------------------------------------------------------ [INFO] Building Unnamed - test:test-main:pom:0.0.1 [INFO] task-segment: [release:prepare] (aggregator-style) [INFO] ------------------------------------------------------------------------ [INFO] [release:prepare {execution: default-cli}] [INFO] Verifying that there are no local modifications... [INFO] Executing: cmd.exe /X /C "cvs -z3 -d :pserver:rt55@cvsserver:/home/cvs/repository/test -n -q update -d" [INFO] Working directory: C:\work\workspaces\maven\test-main [INFO] Checking dependencies and plugins for snapshots ... ... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] [INFO] Reactor Summary: [INFO] [INFO] ------------------------------------------------------------------------ [INFO] [INFO] Unnamed - test:test-main:pom:0.0.1 ...... SUCCESS [3.609s] [INFO] [INFO] Unnamed - test:modul2:jar:0.0.1 ......... SUCCESS [1.157s] [INFO] [INFO] Unnamed - test:modul1:jar:0.0.1 ......... SUCCESS [0.531s] [INFO] [INFO] ------------------------------------------------------------------------ [INFO] [INFO] ------------------------------------------------------------------------ [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] ------------------------------------------------------------------------ [INFO] [INFO] Total time: 5 seconds [INFO] [INFO] Finished at: Tue Aug 24 14:25:39 CEST 2010 [INFO] [INFO] Final Memory: 21M/254M [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Checking in modified POMs... [INFO] Executing: cmd.exe /X /C "cvs -z3 -q commit -R -F C:\DOCUME~1\rt55\LOCALS~1\Temp\scm-commit-message5089.txt pom.xml" [INFO] Working directory: C:\work\workspaces\maven\test-main [INFO] Executing: cmd.exe /X /C "cvs -z3 -q commit -R -F C:\DOCUME~1\rt55\LOCALS~1\Temp\scm-commit-message5091.txt pom.xml" [INFO] Working directory: C:\work\workspaces\maven\test-module2 [INFO] Executing: cmd.exe /X /C "cvs -z3 -q commit -R -F C:\DOCUME~1\rt55\LOCALS~1\Temp\scm-commit-message5093.txt pom.xml" [INFO] Working directory: C:\work\workspaces\maven\test-module1 [INFO] Tagging release with the label test-main-0_0_1... [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] The scm url is invalid. - The connection string contains too few tokens. Now, the changes are correctly checked, so i assume the scm url is correct, or ? <scm> <connection>scm:cvs|pserver|${maven.scm.username}@cvsserver|/home/cvs/repository/test|maventest_main</connection> </scm> Am I doing something wrong ?
          Hide
          Eric Miles added a comment -

          Michael,

          While the flat structure is supported, it's very particular about how it's structured. I wrote a series of blog posts on this. The third in the series can be found at the following link, and that post has pointers to the first 2 (I recommend reading them in order).

          http://ericmiles.wordpress.com/2010/02/08/maven-release-non-supported-scm-structures/

          Show
          Eric Miles added a comment - Michael, While the flat structure is supported, it's very particular about how it's structured. I wrote a series of blog posts on this. The third in the series can be found at the following link, and that post has pointers to the first 2 (I recommend reading them in order). http://ericmiles.wordpress.com/2010/02/08/maven-release-non-supported-scm-structures/
          Hide
          Michael Glauche added a comment - - edited

          After some digging i think the patch for flat modules is broken for cvs. It seems the recent patch to tag SVN correctly did stop CVS from tagging it. If i look into ScmTagPhase the ScmRepository gets initialized with:

          repository =
                scmRepositoryConfigurator.getConfiguredRepository( basedirAlignedReleaseDescriptor.getScmSourceUrl(),
                                                                             releaseDescriptor,
                                                                             releaseEnvironment.getSettings() );
          

          But basedirAlignedReleaseDescriptor.getScmSourceUrl() yields "...cvsserver|/home/cvs/repository", note the missing project AND the missing module ...

          If i change it to the same code the SvnCommitPhase is using things are starting to look better, when i change the ScmFileSetConstructor back to releaseDescriptor.getWorkingDirectory() the tags are written to the main project at least. (But this of course breaks the SVN tagging ...)

          @Eric,
          thanks for the links, nice explanation of the problem, but i'm stuck with cvs, you only present some solution for svn, or did i miss something ?

          Show
          Michael Glauche added a comment - - edited After some digging i think the patch for flat modules is broken for cvs. It seems the recent patch to tag SVN correctly did stop CVS from tagging it. If i look into ScmTagPhase the ScmRepository gets initialized with: repository = scmRepositoryConfigurator.getConfiguredRepository( basedirAlignedReleaseDescriptor.getScmSourceUrl(), releaseDescriptor, releaseEnvironment.getSettings() ); But basedirAlignedReleaseDescriptor.getScmSourceUrl() yields "...cvsserver|/home/cvs/repository", note the missing project AND the missing module ... If i change it to the same code the SvnCommitPhase is using things are starting to look better, when i change the ScmFileSetConstructor back to releaseDescriptor.getWorkingDirectory() the tags are written to the main project at least. (But this of course breaks the SVN tagging ...) @Eric, thanks for the links, nice explanation of the problem, but i'm stuck with cvs, you only present some solution for svn, or did i miss something ?
          Hide
          Mike R. Haller added a comment -

          I'd like to share my use case with you to understand why people may have 'unusual' project structures.
          I think that my problem is the same as the one in this issue, but not sure.
          So, my apologizes if this does not fit 100% and should be posted to MRELEASE-516

          We started with the following set up:

          ModuleA/trunk/pom.xml
          ModuleB/trunk/pom.xml
          ModuleC/trunk/pom.xml
          

          These were more or less independent artifacts and the release process was just releasing those three artifacts individually.
          Every module's pom.xml has its own <scm> element.
          After a while, additional modules were implemented and a common parent pom was introduced, hence the structure became:

          Parent/trunk/pom.xml
          ModuleA/trunk/pom.xml
          ModuleB/trunk/pom.xml
          ...
          ModuleY/trunk/pom.xml
          ModuleZ/trunk/pom.xml
          

          Now, the release process for many modules takes up a lot of time and the idea is to aggregate all the releases into
          a single release step from a release manager point of view. So, a reactor build is put on top of the whole thing:

          Everything/trunk/pom.xml (Modules: ModuleA, ModuleB ... ModuleZ)
          ModuleA/trunk/pom.xml
          ModuleB/trunk/pom.xml
          ...
          ModuleY/trunk/pom.xml
          ModuleZ/trunk/pom.xml
          

          The Everything-pom.xml contains the modules:

          <modules>
          	<module>ModuleA</module>
          	<module>ModuleB</module>
          	<module>...</module>
          	<module>ModuleY</module>
          	<module>ModuleZ</module>
          </modules>
          

          Then, all the trunks are checked out from SCM (SVN, using the svn:externals property) into the local working copy, so they reflect the correct
          structure without any 'trunk' folders or relative paths like "../ModuleA".

          pom.xml (from Everything/trunk/pom.xml)
          + ModuleA/pom.xml
          + ModuleB/pom.xml
          ...
          + ModuleY/pom.xml
          + ModuleZ/pom.xml
          

          Now, i'm trying to perform a release in the root of this folder, e.g. the "Everything" project.
          The reactor will prepare all modules, but unfortunately, the SVN tag of each module is overwritten and becomes incorrect.
          Each module should be committed to its own 'tags/' folder with name and version of the module.
          However, what actually happens is, the release plugin replaces all SCM URLS of each module with the name of the Everything-pom.xml:

          Actually in pom.xml.tag: <url>scm:svn:.../ModuleA/tags/Everything-1.0/ModuleA/trunk</url>
          Expected in pom.xml.tag: <url>scm:svn:.../ModuleA/tags/ModuleA-1.0</url>

          Show
          Mike R. Haller added a comment - I'd like to share my use case with you to understand why people may have 'unusual' project structures. I think that my problem is the same as the one in this issue, but not sure. So, my apologizes if this does not fit 100% and should be posted to MRELEASE-516 We started with the following set up: ModuleA/trunk/pom.xml ModuleB/trunk/pom.xml ModuleC/trunk/pom.xml These were more or less independent artifacts and the release process was just releasing those three artifacts individually. Every module's pom.xml has its own <scm> element. After a while, additional modules were implemented and a common parent pom was introduced, hence the structure became: Parent/trunk/pom.xml ModuleA/trunk/pom.xml ModuleB/trunk/pom.xml ... ModuleY/trunk/pom.xml ModuleZ/trunk/pom.xml Now, the release process for many modules takes up a lot of time and the idea is to aggregate all the releases into a single release step from a release manager point of view. So, a reactor build is put on top of the whole thing: Everything/trunk/pom.xml (Modules: ModuleA, ModuleB ... ModuleZ) ModuleA/trunk/pom.xml ModuleB/trunk/pom.xml ... ModuleY/trunk/pom.xml ModuleZ/trunk/pom.xml The Everything-pom.xml contains the modules: <modules> <module>ModuleA</module> <module>ModuleB</module> <module>...</module> <module>ModuleY</module> <module>ModuleZ</module> </modules> Then, all the trunks are checked out from SCM (SVN, using the svn:externals property) into the local working copy, so they reflect the correct structure without any 'trunk' folders or relative paths like "../ModuleA". pom.xml (from Everything/trunk/pom.xml) + ModuleA/pom.xml + ModuleB/pom.xml ... + ModuleY/pom.xml + ModuleZ/pom.xml Now, i'm trying to perform a release in the root of this folder, e.g. the "Everything" project. The reactor will prepare all modules, but unfortunately, the SVN tag of each module is overwritten and becomes incorrect. Each module should be committed to its own 'tags/' folder with name and version of the module. However, what actually happens is, the release plugin replaces all SCM URLS of each module with the name of the Everything-pom.xml: Actually in pom.xml.tag: <url>scm:svn:.../ModuleA/tags/Everything-1.0/ModuleA/trunk</url> Expected in pom.xml.tag: <url>scm:svn:.../ModuleA/tags/ModuleA-1.0</url>
          Hide
          Hannes Kogler added a comment - - edited

          @Mike R. Haller
          I'm using CVS so I have the problem that the release plugin doesn't work for flat project structures correctly.
          But the other problem you describe about the entry of the reactor/Everything project to the poms of the child projects I also can reconstruct with the <tag> element in the <scm> section..

          this is NOT FIXED at all!

          Show
          Hannes Kogler added a comment - - edited @Mike R. Haller I'm using CVS so I have the problem that the release plugin doesn't work for flat project structures correctly. But the other problem you describe about the entry of the reactor/Everything project to the poms of the child projects I also can reconstruct with the <tag> element in the <scm> section.. this is NOT FIXED at all!
          Hide
          Hannes Kogler added a comment -

          please take a look at MRELEASE-138 too

          Show
          Hannes Kogler added a comment - please take a look at MRELEASE-138 too
          Hide
          cforce added a comment -

          I wanna checkout my code from multiple modules! Arg, will this ever be solved????

          Show
          cforce added a comment - I wanna checkout my code from multiple modules! Arg, will this ever be solved????
          Hide
          Nico De Groote added a comment -

          see my issue MRELEASE-636.
          I'm also waiting for the patch to be applied.

          Show
          Nico De Groote added a comment - see my issue MRELEASE-636 . I'm also waiting for the patch to be applied.

            People

            • Assignee:
              Maria Odea Ching
              Reporter:
              paul.whelan@gmail.com
            • Votes:
              58 Vote for this issue
              Watchers:
              60 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: