Continuum
  1. Continuum
  2. CONTINUUM-1569

Release of a flat structure multi-module project doesn't work

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.4.1
    • Component/s: None
    • Labels:
      None
    • Environment:
      continuum on win-xp, cvs on linux

      Description

      Structure in CVS

      • Parent
      • Ear
      • War
      • Ejb-Jar
      • Java

      In the parent pom:
      <modules>
      <module>../JEEFrameworkRefAppJAVA</module>
      <module>../JEEFrameworkRefAppEJB</module>
      <module>../JEEFrameworkRefAppWAR</module>
      <module>../JEEFrameworkRefAppEAR</module>
      </modules>

      In the child modules poms:
      <parent>
      <groupId>com.te.refapp</groupId>
      <artifactId>JEEFrameworkRefApp</artifactId>
      <version>1.0-SNAPSHOT</version>
      <relativePath>.../JEEFrameworkRefApp/pom.xml</relativePath>
      </parent>

      Adding the parent pom to continuum I had all the projects created and they build successfully when scheduled or when build is forced.

      BUT..

      when I click on release and then "prepare project for release" I get: java.io.FileNotFoundException: C:\build\continuum-1.1-beta-4\apps\continuum\webapp\WEB-INF\working-directory\14\..\JEEFrameworkRefAppJAVA\pom.xml (The system cannot find the path specified)

      Is there something wrong I do or is this a Continuum problem?

      Note that: when we used to have parent pom one level above sub-modules pom, release worked fine. But that kind of structure is not friendly to our development tools so we need to use a flat one.

      Thanks

        Issue Links

          Activity

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          915d 17h 57m 1 Maria Odea Ching 20/May/10 03:12
          Mark Thomas made changes -
          Workflow jira [ 12948565 ] Default workflow, editable Closed status [ 12985836 ]
          Mark Thomas made changes -
          Link This issue is related to SCM-392 [ SCM-392 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 21:12:18 UTC 2015 [ 1428268338676 ]
          Mark Thomas made changes -
          Workflow jira [ 12710226 ] Default workflow, editable Closed status [ 12740821 ]
          Mark Thomas made changes -
          Link This issue is related to SCM-392 [ SCM-392 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 08:36:01 UTC 2015 [ 1428222961749 ]
          Maria Odea Ching made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Closed [ 6 ]
          Hide
          Maria Odea Ching added a comment -

          Resolving issue. Additional improvement mentioned in the linked dev list thread will be filed as separate issues.

          The branch for flat multi-module projects support is already merged to trunk in -r946548.

          Show
          Maria Odea Ching added a comment - Resolving issue. Additional improvement mentioned in the linked dev list thread will be filed as separate issues. The branch for flat multi-module projects support is already merged to trunk in -r946548 .
          Brett Porter made changes -
          Fix Version/s 1.4.1 [ 15104 ]
          Fix Version/s 1.4.0 [ 15106 ]
          Wendy Smoak made changes -
          Link This issue relates to CONTINUUM-1850 [ CONTINUUM-1850 ]
          Hide
          Maria Odea Ching added a comment -

          Additional changes specified in the following still needs to be implemented to the branch:

          http://www.nabble.com/CONTINUUM-1569-and-2193-staged-ts23519500.html

          Show
          Maria Odea Ching added a comment - Additional changes specified in the following still needs to be implemented to the branch: http://www.nabble.com/CONTINUUM-1569-and-2193-staged-ts23519500.html
          Maria Odea Ching made changes -
          Link This issue depends upon CONTINUUM-2193 [ CONTINUUM-2193 ]
          Maria Odea Ching made changes -
          Fix Version/s 1.x [ 14167 ]
          Assignee Maria Odea Ching [ oching ]
          Fix Version/s 1.4.0 [ 15106 ]
          Brett Porter made changes -
          Link This issue is related to CONTINUUM-1298 [ CONTINUUM-1298 ]
          Brett Porter made changes -
          Link This issue is duplicated by CONTINUUM-1298 [ CONTINUUM-1298 ]
          Brett Porter made changes -
          Fix Version/s 1.x [ 14167 ]
          Hide
          Brett Porter added a comment - - edited

          I think CONTINUUM-1657 is the right way to go (and there is probably other duplicates of that issue). I've discussed this a couple of times, and started to work towards it last year - I think what we want in a group is to checkout the common base and run the builds from the one checkout. But there are complications to this - the group would need to have one scm update mechanism, for example. On the up side, less network traffic and disk is used for the parent projects.

          While we should take on a direction towards this, in the short term I think I would go with a more basic approach - allow a project group to use one working directory by a checkbox configuration. When in that mode, you can set them up in the right structure without worrying about handling the nesting case (nested projects should be disallowed in that mode).

          As for releases - as long as it works on checkouts in the same mode it should work. It currently looks for the parent and checks that out, but instead it should seek the commons SCM root and check that out.

          I would keep this split into two issues - the second (releases - this issue) is actually easier to fix and the first (CONTINUUM-1657, builds) is more easily worked around right now.

          Both should be able to be worked around by adding a parent in the root that is just used for checkouts, and building as a non-recursive project.

          Show
          Brett Porter added a comment - - edited I think CONTINUUM-1657 is the right way to go (and there is probably other duplicates of that issue). I've discussed this a couple of times, and started to work towards it last year - I think what we want in a group is to checkout the common base and run the builds from the one checkout. But there are complications to this - the group would need to have one scm update mechanism, for example. On the up side, less network traffic and disk is used for the parent projects. While we should take on a direction towards this, in the short term I think I would go with a more basic approach - allow a project group to use one working directory by a checkbox configuration. When in that mode, you can set them up in the right structure without worrying about handling the nesting case (nested projects should be disallowed in that mode). As for releases - as long as it works on checkouts in the same mode it should work. It currently looks for the parent and checks that out, but instead it should seek the commons SCM root and check that out. I would keep this split into two issues - the second (releases - this issue) is actually easier to fix and the first ( CONTINUUM-1657 , builds) is more easily worked around right now. Both should be able to be worked around by adding a parent in the root that is just used for checkouts, and building as a non-recursive project.
          Hide
          Maria Odea Ching added a comment -

          This would require two fixes:

          1. in Continuum
          2. in the Release Manager (which Emmanuel pointed out above).

          For number 1:
          Currently, releasing a flat multi-module project in Continuum results to the following error:

          Unable to get release plugin parameters and process project - /home/deng/Projects/continuum-1.3.x/continuum-jetty/target/apache-continuum-1.3.3-SNAPSHOT/data/working-directory/1/../module-a/pom.xml (No such file or directory)
          

          This is because in the working directory, the flat multi-module project is checked out as follows:

          |-- 1 (module-a and b's PARENT)
          |   `-- pom.xml
          |-- 2 (module-a)
          |   |-- pom.xml
          |   '-- src
          |       `-- main
          |           `-- ...
          '-- 3 (module-b)
              |-- pom.xml
              '-- src
                  '-- main
                      `-- ...
          

          Whereas, a non-flat multi-module project is checked out as follows:

          |-- 1
          |   |-- pom.xml
          |   |-- module-a
          |   |   |-- pom.xml
          |   |   `-- src
          |   |       '-- main
          |   |           `-- ..
          |   '-- module-b
          |       |-- pom.xml
          |       `-- src
          |           '-- main
          |               '-- ...
          |-- 2 (module-a)
          |   |-- pom.xml
          |   '-- src
          |       '-- main
          |           `-- ...
          `-- 3 (module-b)
              |-- pom.xml
              '-- src
                  '-- main
                      '-- ...
          

          So when the flat multi-module project is released, the sub-modules aren't found because Continuum looks for them in /1/../module-a/ and /1/../module-b respectively.

          I haven't reviewed the proposed solution in CONTINUUM-1657 if it would be a good fix for this.

          For number 2:
          Releasing a flat multi-module project from the command line results to only the parent project being tagged and released. The versions of the sub-modules are updated though, they just weren't tagged.

          I looked briefly at the release-manager's code, maybe the release-manager can execute 'svn copy ...' on each module if the project to be released is a flat multi-module. Either set a field in the release descriptor telling the release manager that the project is a flat multi-module or have the release manager determine this on it's own, I'm not sure.

          Comments anyone?

          Show
          Maria Odea Ching added a comment - This would require two fixes: in Continuum in the Release Manager (which Emmanuel pointed out above). For number 1: Currently, releasing a flat multi-module project in Continuum results to the following error: Unable to get release plugin parameters and process project - /home/deng/Projects/continuum-1.3.x/continuum-jetty/target/apache-continuum-1.3.3-SNAPSHOT/data/working-directory/1/../module-a/pom.xml (No such file or directory) This is because in the working directory, the flat multi-module project is checked out as follows: |-- 1 (module-a and b's PARENT) | `-- pom.xml |-- 2 (module-a) | |-- pom.xml | '-- src | `-- main | `-- ... '-- 3 (module-b) |-- pom.xml '-- src '-- main `-- ... Whereas, a non-flat multi-module project is checked out as follows: |-- 1 | |-- pom.xml | |-- module-a | | |-- pom.xml | | `-- src | | '-- main | | `-- .. | '-- module-b | |-- pom.xml | `-- src | '-- main | '-- ... |-- 2 (module-a) | |-- pom.xml | '-- src | '-- main | `-- ... `-- 3 (module-b) |-- pom.xml '-- src '-- main '-- ... So when the flat multi-module project is released, the sub-modules aren't found because Continuum looks for them in /1/../module-a/ and /1/../module-b respectively. I haven't reviewed the proposed solution in CONTINUUM-1657 if it would be a good fix for this. For number 2: Releasing a flat multi-module project from the command line results to only the parent project being tagged and released. The versions of the sub-modules are updated though, they just weren't tagged. I looked briefly at the release-manager's code, maybe the release-manager can execute 'svn copy ...' on each module if the project to be released is a flat multi-module. Either set a field in the release descriptor telling the release manager that the project is a flat multi-module or have the release manager determine this on it's own, I'm not sure. Comments anyone?
          Brett Porter made changes -
          Fix Version/s Future [ 13292 ]
          Wendy Smoak made changes -
          Fix Version/s Future [ 13292 ]
          Fix Version/s 1.x [ 14167 ]
          Hide
          Aidas Šemežys added a comment -

          Hello, everyone,

          Has anybody solved this issue?
          Could anyone share the knowledge of the solution with the community?
          I thinks this is a blocker feature. And continuum/maven team should solve it as quickly as possible. Otherwise, it seems like non-respect to the community.

          Thanks in advance.

          Show
          Aidas Šemežys added a comment - Hello, everyone, Has anybody solved this issue? Could anyone share the knowledge of the solution with the community? I thinks this is a blocker feature. And continuum/maven team should solve it as quickly as possible. Otherwise, it seems like non-respect to the community. Thanks in advance.
          Hide
          Chris Graham added a comment -

          It is related to SCM-392, however, once you fix the flat structure for SVN to work, you end up with the release manager not coping with the flat structure either - which I think is the true underlying cause of this issue.

          In general, the entire issue of flat structures needs to be addressed, and IMHO, quickly.

          -Chris

          Show
          Chris Graham added a comment - It is related to SCM-392 , however, once you fix the flat structure for SVN to work, you end up with the release manager not coping with the flat structure either - which I think is the true underlying cause of this issue. In general, the entire issue of flat structures needs to be addressed, and IMHO, quickly. -Chris
          Hide
          Wendy Smoak added a comment -

          May be related to SCM-392

          Show
          Wendy Smoak added a comment - May be related to SCM-392
          Wendy Smoak made changes -
          Link This issue is related to SCM-392 [ SCM-392 ]
          Hide
          Karsten Thoms added a comment -

          Another workaround for *nix systems is to add symbolic links in the working directory that point to the actual working directory of the submodules.

          ln -s <projectid> <artifactid>
          example:
          ln -s 14 JEEFrameworkRefApp
          ln -s 15 JEEFrameworkRefAppJAVA

          Drawback: This will only work for one instance of the multimodule project. If you maintain branch builds this won't work.

          Show
          Karsten Thoms added a comment - Another workaround for *nix systems is to add symbolic links in the working directory that point to the actual working directory of the submodules. ln -s <projectid> <artifactid> example: ln -s 14 JEEFrameworkRefApp ln -s 15 JEEFrameworkRefAppJAVA Drawback: This will only work for one instance of the multimodule project. If you maintain branch builds this won't work.
          Brett Porter made changes -
          Link This issue is duplicated by CONTINUUM-1298 [ CONTINUUM-1298 ]
          Brett Porter made changes -
          Link This issue is related to CONTINUUM-1657 [ CONTINUUM-1657 ]
          Brett Porter made changes -
          Field Original Value New Value
          Fix Version/s 1.x [ 14167 ]
          Hide
          Gianni Buzzeri added a comment -

          Your suggestion worked fine.. now both continuum and our development tools are happy.

          But before that, I needed another workaround (MJAVADOC-161) to make the release not fail.

          Thanks

          Show
          Gianni Buzzeri added a comment - Your suggestion worked fine.. now both continuum and our development tools are happy. But before that, I needed another workaround ( MJAVADOC-161 ) to make the release not fail. Thanks
          Hide
          Emmanuel Venisse added a comment -

          It's a problem in the release manager used by Continuum and the release plugin.
          A workaround would be to create a parent pom in the root directory and use it in your Parent/pom.xml. In this pom, you can add minimal information, all informations you want to share with submodules can be continue to be in your Parent/pom.xml
          Then you'll do the release on it.

          Show
          Emmanuel Venisse added a comment - It's a problem in the release manager used by Continuum and the release plugin. A workaround would be to create a parent pom in the root directory and use it in your Parent/pom.xml. In this pom, you can add minimal information, all informations you want to share with submodules can be continue to be in your Parent/pom.xml Then you'll do the release on it.
          Gianni Buzzeri created issue -

            People

            • Assignee:
              Maria Odea Ching
              Reporter:
              Gianni Buzzeri
            • Votes:
              3 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development