Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta-5
    • Fix Version/s: 2.0-beta-5
    • Component/s: None
    • Labels:
      None
    • Environment:
      Windows XP, Eclipse Workspace
    • Number of attachments :
      0

      Description

      I tried to release a multiproject with 5 modules (on a Branch). Well,
      the POMs of all modules are changed and there are some dependencies
      which have been updated correctly. But only the master has been checked
      in correctly.

      I'm changed the recommended layout, to fit in an eclipse workspace. I
      have one master at the same level as the other modules.

      The module section of the master pom.xml:

      <modules>
      <module>../hhla.library.pom</module>
      <module>../hhla.library.site</module>
      <module>../hhla.lang</module>
      <module>../hhla.common.log4jx</module>
      </modules>

        Issue Links

          Activity

          Hide
          azgard added a comment -

          My modules in root-pom-xml looks like:

          <modules>
          <module>../core</module>
          <module>../app</module>
          <module>../export</module>
          </modules>

          The "commitByProject" for prepare goal works well and he does the preparation.

          But when I then perform the release goal I get a FileNotFoundException for the sub-modules pom.xml.

          He looks for the sub-module pom.xml in the root-project root/target/checkout folder.

          Any hints?

          Show
          azgard added a comment - My modules in root-pom-xml looks like: <modules> <module>../core</module> <module>../app</module> <module>../export</module> </modules> The "commitByProject" for prepare goal works well and he does the preparation. But when I then perform the release goal I get a FileNotFoundException for the sub-modules pom.xml. He looks for the sub-module pom.xml in the root-project root/target/checkout folder. Any hints?
          Hide
          Emmanuel Venisse added a comment -

          It's a bug, file a new issue.
          As a workaround, you can checkout your sub-modules into the checkout directory, I'm not sure it will work

          Show
          Emmanuel Venisse added a comment - It's a bug, file a new issue. As a workaround, you can checkout your sub-modules into the checkout directory, I'm not sure it will work
          Hide
          werner mueller added a comment -

          hallo

          this bug is linked at http://maven.apache.org/guides/mini/guide-ide-eclipse.html
          and in maven 2.0.7 this does not seem to be 'fixed'

          are there any plans to support flat structures? or to refer to modules using groupId and artifactId (so one could create a logical structure which may not be the same as the physical structure)?

          thanks

          Show
          werner mueller added a comment - hallo this bug is linked at http://maven.apache.org/guides/mini/guide-ide-eclipse.html and in maven 2.0.7 this does not seem to be 'fixed' are there any plans to support flat structures? or to refer to modules using groupId and artifactId (so one could create a logical structure which may not be the same as the physical structure)? thanks
          Hide
          John Allen added a comment -

          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.

          Will be provide a patch for this fix shortly against MRELEASE-261

          Show
          John Allen added a comment - 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. Will be provide a patch for this fix shortly against MRELEASE-261
          Hide
          Tristan Robert added a comment -

          This issue is similar to MRELEASE-261 which is not fixed.

          Show
          Tristan Robert added a comment - This issue is similar to MRELEASE-261 which is not fixed.

            People

            • Assignee:
              Emmanuel Venisse
              Reporter:
              Bernd Mau
            • Votes:
              40 Vote for this issue
              Watchers:
              46 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: