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

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.

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

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.

May be related to SCM-392

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

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.

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?

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.

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

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.