Multiproject Release: No check in

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 ?

see also CONTINUUM-462

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

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.

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

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

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?

so, the fix here needs to be that we check in every module individually, unless its a subdirectory of some other module?

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.

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.

Done. Need to use the 'commitByProject' parameter of prepare mojo

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?

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

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

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

This issue is similar to MRELEASE-261 which is not fixed.