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

depends upon

CONTINUUM-2193Add option to check out a multi-module project into a single working directory

Activity

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.

Emmanuel Venisse
added a comment - 16/Nov/07 9:42 AM 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.

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.

Aidas Šemežys
added a comment - 03/Apr/09 6:35 AM 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.

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.

Maria Odea Ching
added a comment - 21/Apr/09 5:57 AM 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?

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.

Brett Porter
added a comment - 21/Apr/09 6:09 AM - 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.

Maria Odea Ching
added a comment - 16/Jul/09 8:21 PM 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