Details

    • Type: Bug Bug
    • Status: 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

      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

          Bernd Mau created issue -
          Hide
          Christian Schulte added a comment -

          This is not only a problem of the release plugin its also a problem with inheritance in Maven 2 in general. Its completely ignoring relative path settings during inheritance when building SCM-URLs and URLs. Looking at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler it seems the following assumptions have been made:

          1. The artifactId is always the same as the directory-name holding the artifact
          2. The parent "lives" always one level up in the hierarchy

          So no matter what relative path settings are specified they are ignored in that class which builds various paths during inheritance. I am currently thinking about fixing this class but I would need some guidance to not break anything since I do not know what assumptions have been made further and if it is really only this class to fix.

          A workaround for this problem is to not inherit things build from this class by e.g. specifying the SCM-URLs inside every pom and do not let maven build them for you during inheritance which holds true also for URLs.

          Would it lead to problems if this class would support the relative paths without changing anything else ?

          Show
          Christian Schulte added a comment - This is not only a problem of the release plugin its also a problem with inheritance in Maven 2 in general. Its completely ignoring relative path settings during inheritance when building SCM-URLs and URLs. Looking at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler it seems the following assumptions have been made: 1. The artifactId is always the same as the directory-name holding the artifact 2. The parent "lives" always one level up in the hierarchy So no matter what relative path settings are specified they are ignored in that class which builds various paths during inheritance. I am currently thinking about fixing this class but I would need some guidance to not break anything since I do not know what assumptions have been made further and if it is really only this class to fix. A workaround for this problem is to not inherit things build from this class by e.g. specifying the SCM-URLs inside every pom and do not let maven build them for you during inheritance which holds true also for URLs. Would it lead to problems if this class would support the relative paths without changing anything else ?
          Hide
          Christian Schulte added a comment -

          see also CONTINUUM-462

          Show
          Christian Schulte added a comment - see also CONTINUUM-462
          Jason van Zyl made changes -
          Field Original Value New Value
          Component/s maven-release-plugin [ 11800 ]
          Project Maven 2 [ 10500 ] Maven 2.x Release Plugin [ 11144 ]
          Affects Version/s 2.0 [ 11703 ]
          Workflow Maven [ 40809 ] jira [ 44274 ]
          Key MNG-1263 MRELEASE-6
          Jason van Zyl made changes -
          Workflow jira [ 44274 ] Maven [ 44941 ]
          Hide
          Kenney Westerhof added a comment -

          1) that is best practise. But having a module directory 'a' containing a pom with artifactId 'b' should work though.
          2) Correct, that is the default. When scanning for parent poms, first ../pom.xml is checked to see if it matches
          the <parent> tag. If that fails, the local/remote repositories are consulted for that pom.

          The problem here with the SCM module is that if your CVS/Subversion/Whatever repository layout does
          not match the default parent/module inheritance model (module = artifactId subdir, parent = ..),
          you have to specify the SCMUrl in every pom. Only when the default layout is used, Maven can make a
          well educated guess on the SCM url.
          The same goes for site urls, btw.

          In theory, maven should use the <module> definitions to define SCM urls for child modules.
          But it poses some problems. Say you want to release a submodule. You do the release there.
          Maven will try to guess the SCM url by traversing the parent-tree until an SCM url is found
          (actually it'll go all the way up to the built-in root pom..).
          It first tries ../pom.xml, which does not exist. It then retrieves the pom from the repository. Since there's no
          relation between the module directory name and the artifactId, it cannot see which of the <module> tags
          corresponds to the project you're currently trying to release. It can only append the current artifactId
          to that SCM url and hope it's correct.

          I hope this clarifies a lot. There is no easy solution..

          Show
          Kenney Westerhof added a comment - 1) that is best practise. But having a module directory 'a' containing a pom with artifactId 'b' should work though. 2) Correct, that is the default. When scanning for parent poms, first ../pom.xml is checked to see if it matches the <parent> tag. If that fails, the local/remote repositories are consulted for that pom. The problem here with the SCM module is that if your CVS/Subversion/Whatever repository layout does not match the default parent/module inheritance model (module = artifactId subdir, parent = ..), you have to specify the SCMUrl in every pom. Only when the default layout is used, Maven can make a well educated guess on the SCM url. The same goes for site urls, btw. In theory, maven should use the <module> definitions to define SCM urls for child modules. But it poses some problems. Say you want to release a submodule. You do the release there. Maven will try to guess the SCM url by traversing the parent-tree until an SCM url is found (actually it'll go all the way up to the built-in root pom..). It first tries ../pom.xml, which does not exist. It then retrieves the pom from the repository. Since there's no relation between the module directory name and the artifactId, it cannot see which of the <module> tags corresponds to the project you're currently trying to release. It can only append the current artifactId to that SCM url and hope it's correct. I hope this clarifies a lot. There is no easy solution..
          Hide
          Kenney Westerhof added a comment -

          One more thing: only <type>pom</type> projects can have modules.
          So I don't see any reason not to add a root pom that specifies your four modules. That way
          you can have a normal tree with the modules as direct children (in the sub-directory-sense)
          as was intended:

          master/
          /hhla....
          /hhla...

          Since the master would have packaging pom, it won't get included in eclipse, since it does not
          produce any artifacts. I do this all the time and have absolutely no problems with it.

          Show
          Kenney Westerhof added a comment - One more thing: only <type>pom</type> projects can have modules. So I don't see any reason not to add a root pom that specifies your four modules. That way you can have a normal tree with the modules as direct children (in the sub-directory-sense) as was intended: master/ /hhla.... /hhla... Since the master would have packaging pom, it won't get included in eclipse, since it does not produce any artifacts. I do this all the time and have absolutely no problems with it.
          Hide
          Olivier Lamy (*$^¨%`£) added a comment -

          Personnaly, I named directory (module and scm) striclty equals ( ).
          In fact, I used something like this

          • root-module/pom.xml
            src/site/global documentation
          • api-module/pom.xml
          • ....

          root-module as this to edit it with eclipse.
          But it's easy to change to
          ./pom.xml (root)
          site-module with global documentation
          not a real trouble
          Thanks,
          Olivier

          Show
          Olivier Lamy (*$^¨%`£) added a comment - Personnaly, I named directory (module and scm) striclty equals ( ). In fact, I used something like this root-module/pom.xml src/site/global documentation api-module/pom.xml .... root-module as this to edit it with eclipse. But it's easy to change to ./pom.xml (root) site-module with global documentation not a real trouble Thanks, Olivier
          Brett Porter made changes -
          Workflow Maven [ 44941 ] Maven New [ 52266 ]
          Hide
          Fabian Bauschulte added a comment -

          I am using CVS and eclipse (workspace). All my projects are CVS modules: parent and moduleA, modulesB, moduleC:
          \parent
          \moduleA
          \moduleB
          \moduleC
          Every project has the section "<scm><developerConnection>xxx</developerConnection></scm>" set to the correct cvs location. Refactoring of the package structure is not possible in my case (legacy system).
          I don´t see a way to use the multiproject release - any solution would be highly appreciated.

          At the moment I am forced to release all modules "my hand":
          \parent\mvn -N release:prepare release:perform
          \moduleA\mvn release:prepare release:perform
          \moduleB\mvn release:prepare release:perform
          \moduleC\mvn release:prepare release:perform

          Is there any chance to get this bug fixed in the next time??

          Show
          Fabian Bauschulte added a comment - I am using CVS and eclipse (workspace). All my projects are CVS modules: parent and moduleA, modulesB, moduleC: \parent \moduleA \moduleB \moduleC Every project has the section "<scm><developerConnection>xxx</developerConnection></scm>" set to the correct cvs location. Refactoring of the package structure is not possible in my case (legacy system). I don´t see a way to use the multiproject release - any solution would be highly appreciated. At the moment I am forced to release all modules "my hand": \parent\mvn -N release:prepare release:perform \moduleA\mvn release:prepare release:perform \moduleB\mvn release:prepare release:perform \moduleC\mvn release:prepare release:perform Is there any chance to get this bug fixed in the next time??
          Hide
          Todd Nine added a comment -

          I agree that making assumptions about the scm url in an eclipse "flat" directory structure is not a good implementation. However if each pom explicitly states the scmurl, why is that not used in the reactor as each child is built? Can that simply be the required behavior in order to fix this bug when using a flat directory structure?

          Show
          Todd Nine added a comment - I agree that making assumptions about the scm url in an eclipse "flat" directory structure is not a good implementation. However if each pom explicitly states the scmurl, why is that not used in the reactor as each child is built? Can that simply be the required behavior in order to fix this bug when using a flat directory structure?
          Todd Nine made changes -
          Link This issue is related to MRELEASE-94 [ MRELEASE-94 ]
          Turadg Aleahmad made changes -
          Link This issue is duplicated by CONTINUUM-462 [ CONTINUUM-462 ]
          Hide
          Brett Porter added a comment -

          so, the fix here needs to be that we check in every module individually, unless its a subdirectory of some other module?

          Show
          Brett Porter added a comment - so, the fix here needs to be that we check in every module individually, unless its a subdirectory of some other module?
          Brett Porter made changes -
          Fix Version/s 2.0-beta-4 [ 12367 ]
          Brett Porter made changes -
          Fix Version/s 2.0 [ 12571 ]
          Fix Version/s 2.0-beta-4 [ 12367 ]
          Hide
          Dominik Doll added a comment -

          Hi,
          i have found this issue, because i have the same problem with Eclipse and Maven2 multi-projects.
          Do you plan to make a bugfix for that error ? Do somebody have a work-a-round (without releaseing each project by hand !!!) ?

          Show
          Dominik Doll added a comment - Hi, i have found this issue, because i have the same problem with Eclipse and Maven2 multi-projects. Do you plan to make a bugfix for that error ? Do somebody have a work-a-round (without releaseing each project by hand !!!) ?
          Jason van Zyl made changes -
          Fix Version/s 2.0 [ 12571 ]
          Jason van Zyl made changes -
          Assignee Jason van Zyl [ jason ]
          Jason van Zyl made changes -
          Affects Version/s 2.0-beta-5 [ 13024 ]
          Jason van Zyl made changes -
          Fix Version/s 2.0-beta-5 [ 13024 ]
          Hide
          Wouter Boers added a comment -

          Just zoomin in on the eclipse problem.

          There is an easy workaround for the flat project layout. Do not use the src specification in the .classpath file but use the 'link' functionality which is stored in the .project file.

          Show
          Wouter Boers added a comment - Just zoomin in on the eclipse problem. There is an easy workaround for the flat project layout. Do not use the src specification in the .classpath file but use the 'link' functionality which is stored in the .project file.
          Emmanuel Venisse made changes -
          Comment [ http://www.chatarea.com/freecisco21.f81887-1
          http://www.chatarea.com/freecisco21.f81887
          http://www.chatarea.com/freecisco21.f81887-2
          http://www.chatarea.com/freecisco21.f81887-3
          http://www.chatarea.com/freecisco21.f81887-4
          http://www.chatarea.com/freecisco21.m3876846
          http://www.chatarea.com/freecisco21.m3876845
          http://www.chatarea.com/freecisco21.m3876844
          http://www.chatarea.com/freecisco21.m3876843
          http://www.chatarea.com/freecisco21.m3876842
          http://www.chatarea.com/freecisco21.m3876841
          http://www.chatarea.com/freecisco21.m3876840
          http://www.chatarea.com/freecisco21.m3876839
          http://www.chatarea.com/freecisco21.m3876838
          http://www.chatarea.com/freecisco21.m3876837
          http://www.chatarea.com/freecisco21.m3876836
          http://www.chatarea.com/freecisco21.m3876834
          http://www.chatarea.com/freecisco21.m3876832
          http://www.chatarea.com/freecisco21.m3876831
          http://www.chatarea.com/freecisco21.m3876830
          http://www.chatarea.com/freecisco21.m3876828
          http://www.chatarea.com/freecisco21.m3876826
          http://www.chatarea.com/freecisco21.m3876824
          http://www.chatarea.com/freecisco21.m3876823
          http://www.chatarea.com/freecisco21.m3876822
          http://www.chatarea.com/freecisco21.m3876820
          http://www.chatarea.com/freecisco21.m3876819
          http://www.chatarea.com/freecisco21.m3876818
          http://www.chatarea.com/freecisco21.m3876817
          http://www.chatarea.com/freecisco21.m3876816
          http://www.chatarea.com/freecisco21.m3876815
          http://www.chatarea.com/freecisco21.m3876813
          http://www.chatarea.com/freecisco21.m3876812
          http://www.chatarea.com/freecisco21.m3876811
          http://www.chatarea.com/freecisco21.m3876810
          http://www.chatarea.com/freecisco21.m3876809
          http://www.chatarea.com/freecisco21.m3876808
          http://www.chatarea.com/freecisco21.m3876806
          http://www.chatarea.com/freecisco21.m3876805
          http://www.chatarea.com/freecisco21.m3876804
          http://www.chatarea.com/freecisco21.m3876801
          http://www.chatarea.com/freecisco21.m3876800
          http://www.chatarea.com/freecisco21.m3876799
          http://www.chatarea.com/freecisco21.m3876797
          http://www.chatarea.com/freecisco21.m3876796
          http://www.chatarea.com/freecisco21.m3876794
          http://www.chatarea.com/freecisco21.m3876793
          http://www.chatarea.com/freecisco21.m3876792
          http://www.chatarea.com/freecisco21.m3876790
          http://www.chatarea.com/freecisco21.m3876789
          http://www.chatarea.com/freecisco21.m3876788
          http://www.chatarea.com/freecisco21.m3876787
          http://www.chatarea.com/freecisco21.m3876786
          http://www.chatarea.com/freecisco21.m3876785
          http://www.chatarea.com/freecisco21.m3876782
          http://www.chatarea.com/freecisco21.m3876781
          http://www.chatarea.com/freecisco21.m3876780
          http://www.chatarea.com/freecisco21.m3876779
          http://www.chatarea.com/freecisco21.m3876778
          http://www.chatarea.com/freecisco21.m3876776
          http://www.chatarea.com/freecisco21.m3876775
          http://www.chatarea.com/freecisco21.m3876774
          http://www.chatarea.com/freecisco21.m3876773
          http://www.chatarea.com/freecisco21.m3876771
          http://www.chatarea.com/freecisco21.m3876770
          http://www.chatarea.com/freecisco21.m3876769
          http://www.chatarea.com/freecisco21.m3876768
          http://www.chatarea.com/freecisco21.m3876767
          http://www.chatarea.com/freecisco21.m3876766
          http://www.chatarea.com/freecisco21.m3876765
          http://www.chatarea.com/freecisco21.m3876764
          http://www.chatarea.com/freecisco21.m3876763
          http://www.chatarea.com/freecisco21.m3876762
          http://www.chatarea.com/freecisco21.m3876761
          http://www.chatarea.com/freecisco21.m3876759
          http://www.chatarea.com/freecisco21.m3876758
          http://www.chatarea.com/freecisco21.m3876757
          http://www.chatarea.com/freecisco21.m3876756
          http://www.chatarea.com/freecisco21.m3876755
          http://www.chatarea.com/freecisco21.m3876754
          http://www.chatarea.com/freecisco21.m3876753
          http://www.chatarea.com/freecisco21.m3876752
          http://www.chatarea.com/freecisco21.m3876751
          http://www.chatarea.com/freecisco21.m3876750
          http://www.chatarea.com/freecisco21.m3876749
          http://www.chatarea.com/freecisco21.m3876748
          http://www.chatarea.com/freecisco21.m3876747
          http://www.chatarea.com/freecisco21.m3876746
          http://www.chatarea.com/freecisco21.m3876745
          http://www.chatarea.com/freecisco21.m3876740
          http://www.chatarea.com/freecisco21.m3876739
          http://www.chatarea.com/freecisco21.m3876738
          http://www.chatarea.com/freecisco21.m3876737
          http://www.chatarea.com/freecisco21.m3876736
          http://www.chatarea.com/freecisco21.m3876735
          http://www.chatarea.com/freecisco21.m3876734
          http://www.chatarea.com/freecisco21.m3876733
          http://www.chatarea.com/freecisco21.m3876732
          http://www.chatarea.com/freecisco21.m3876729
          http://www.chatarea.com/freecisco21.m3876727
          http://www.chatarea.com/freecisco21.m3876726
          http://www.chatarea.com/freecisco21.m3876724
          http://www.chatarea.com/freecisco21.m3876722
          http://www.chatarea.com/freecisco21.m3876720
          http://www.chatarea.com/freecisco21.m3876719





          ]
          Emmanuel Venisse made changes -
          Link This issue is duplicated by MRELEASE-138 [ MRELEASE-138 ]
          Emmanuel Venisse made changes -
          Link This issue is duplicated by MRELEASE-153 [ MRELEASE-153 ]
          Hide
          Christian Hall added a comment - - edited

          I think we are also forced to have our parent pom and our master pom (the one that has the modules defined in it) be the same pom file due to this issue. Would be nice to not require this as sometimes the master pom needs its own parentage compared to an actual component project.

          And to clarify, if the parent POM needs to be updated and installed into the repository, it requires a complete build of all the modules as well, which makes this a bit inconvenient.

          Show
          Christian Hall added a comment - - edited I think we are also forced to have our parent pom and our master pom (the one that has the modules defined in it) be the same pom file due to this issue. Would be nice to not require this as sometimes the master pom needs its own parentage compared to an actual component project. And to clarify, if the parent POM needs to be updated and installed into the repository, it requires a complete build of all the modules as well, which makes this a bit inconvenient.
          Emmanuel Venisse made changes -
          Link This issue is related to MRELEASE-168 [ MRELEASE-168 ]
          Hide
          Emmanuel Venisse added a comment -

          Done. Need to use the 'commitByProject' parameter of prepare mojo

          Show
          Emmanuel Venisse added a comment - Done. Need to use the 'commitByProject' parameter of prepare mojo
          Emmanuel Venisse made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Assignee Jason van Zyl [ jason ] Emmanuel Venisse [ evenisse ]
          Hide
          Conny Kreyßel 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
          Conny Kreyßel 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
          skaze 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
          skaze 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.
          Tristan Robert made changes -
          Link This issue duplicates MRELEASE-261 [ MRELEASE-261 ]
          Tristan Robert made changes -
          Link This issue duplicates MRELEASE-261 [ MRELEASE-261 ]
          Tristan Robert made changes -
          Link This issue is duplicated by MRELEASE-261 [ MRELEASE-261 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 12:15:05 UTC 2015 [ 1428236105845 ]
          Mark Thomas made changes -
          Workflow jira [ 12723861 ] Default workflow, editable Closed status [ 12763051 ]
          Mark Thomas made changes -
          Project Import Mon Apr 06 00:52:26 UTC 2015 [ 1428281546237 ]
          Mark Thomas made changes -
          Workflow jira [ 12961666 ] Default workflow, editable Closed status [ 12998525 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          550d 5h 50m 1 Emmanuel Venisse 24/Apr/07 09:41

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development