wrong SVN directory path created when using cascaded pom modules(?)

sorry I forgot that leading spaces are lost.... the "sub-module-pom" in my sketched "directory layout" is not indented correctly (imagine 4-6 spaces on the left, than the layout is fine "sub-module-pom" is contained within the sub-directory "configuration".

Please share with us the <scm> configuration from your parent and configuration POMs.

Hello Denis.
See below the scm configuration. this configuration is only contained once in the root pom which also defines the modules (thanks for the beautiful formatting)

<scm>
   <connection>scm:svn:https://user:password@myserver.de/svn/***/trunk</connection> 
   <url>scm:svn:https://user:password@myserver.de/svn/***/trunk</url>
   <developerConnection>scm:svn:https://user:password@myserver.de/svn/***/trunk</developerConnection>
</scm>

When a child module doesn't specify an <scm> element, it will inherit one from the parent. During this inheritance the artifactId of the child will be appended to the <scm> URLs from the parent. In your case the inherited <scm> URLs for the child project will look like this

<scm>
   <connection>scm:svn:https://user:password@myserver.de/svn/***/trunk/PREFIX-configuration</connection> 
   <url>scm:svn:https://user:password@myserver.de/svn/***/trunk/PREFIX-configuration</url>
   <developerConnection>scm:svn:https://user:password@myserver.de/svn/***/trunk/PREFIX-configuration</developerConnection>
</scm>

This is the expected behavior.

If you want to use other URLs you will need to specify them explicitly in the POM of your child project, like this:

<scm>
   <connection>scm:svn:https://user:password@myserver.de/svn/***/trunk/configuration</connection> 
   <url>scm:svn:https://user:password@myserver.de/svn/***/trunk/configuration</url>
   <developerConnection>scm:svn:https://user:password@myserver.de/svn/***/trunk/configuration</developerConnection>
</scm>

I believe I have the same problem. What goes wrong in my case is that the url is based on the parent but it should be based on the aggregator (see http://maven.apache.org/pom.html#Inheritance_v )

A project doesn't inherit from an aggregator project - it inherits from a parent project. The aggregator merely triggers the build of a bunch of projects simultaneously.

I expected the SVN path to be in line with the one that is by default used in the release plugin (if I don't specify a scm element in the child project). And the release plugin seems to use the aggregate (though I don't the exact algorithm how it creates the url).

And to me it makes sense that the SVN path uses the aggregator since these are typically tagged together (for the same reason that you mentioned that they are built simultaneously). The parent on the other hand is just providing defaults at definition time. In my case, it is the parent of completely unrelated projects for which it doesn't make sense to tag them together (or any other runtime mvn task)

OK, I'll try again, this time with feeling:

The path to a child directory, when using the aggregator, is not used when constructing the SCM URLs. Only the artifactId is used.

If you want to examine what your POM looks like you can run this command:
mvn help:effective-pom

Ah ok that makes sense. The effective-pom showed that the SCM URLs were different than I thought they were, when I refer to a released version of the parent pom. In that case the SCM url of the parent pom is changed to a tags/parent-pom-<version>. I assumed that what was specified under the SCM element in the parent just served as a template, but in case of a release it is changed to the actual url.

Maybe something can be added to the FAQ about checking the SCM element in the effective-pom since that is quite helpful to get more insight in more complex situations. And it makes perfectly clear when the source of the unexpected behavior is outside the scope of the changelog plugin.
Anyway, thanks for your explanation Dennis!

I added an entry on the FAQ page about SCM URL inheritance.