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
          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
          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
          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?
          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?
          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 !!!) ?
          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.
          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.
          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
          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: