Continuum
  1. Continuum
  2. CONTINUUM-1569

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

    Details

    • Type: Bug Bug
    • Status: Closed 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
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      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

          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
          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?
          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 -

          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
          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 .

            People

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

              Dates

              • Created:
                Updated:
                Resolved: