I really have problems convincing my colleagues to switch to Maven when such a bug is not fixed for month.

Details on: http://maven.apache.org/guides/mini/guide-site.html
Note: the trailing slash in the URL above indicates that any subprojects that inherit this value should append their artifact ID to the path instead of using it as-is.

My solution, the method assembleDistributionInheritence(...) should be modified like this:

...
if ( childDistMgmt.getSite() == null )
{
if ( parentDistMgmt.getSite() != null )
{
Site site = new Site();
childDistMgmt.setSite( site );
site.setId( parentDistMgmt.getSite().getId() );
site.setName( parentDistMgmt.getSite().getName() );
site.setUrl( parentDistMgmt.getSite().getUrl() );
// modification, add the .endWith("/") to the condition
if ( site.getUrl() != null && site.getUrl().endsWith( "/" ) )

}
}
...

The proper solution seems to be to add a POM attribute/element like either:

• use-inherited-urls with a default of false
• append-artifactId-to-parent-urls with a default of true
  But this requires a change to the POM schema which I suspect will be much harder to organise..

A temporary solution might be to do the same thing using well-documented POM properties, eg

• mng-3244-use-inherited-urls with a default of false
• mng-3244-append-artifactId-to-parent-urls with a default of true
  And when (hopefully not if) the POM schema is changed to accomodate the proper solution the implementation can be readily switched from one to the other and even handle fallback and notification of the appropriate configuration.

This patch breaks existing behavior (the docs are wrong).

Well, then you might find this patch useful, intended to save users from confusion and providing some further tweaks to the guide. It's one thing to have a controversal behavior but it's definitively a bad thing to have incorrect documentation.

We have had to declare explicit project.url and distroManagement.site.url elements in EVERY pom of our multi-module proejcts because we also use real identifying information in these URLS, namely the ${project.groupId}/${project.artifactId}/${project.version}

As I understand it; the current rule implements implicit URLs as
${parent.url}/${project.artifactId}

For example:
<scm>
<connection>${parentPOM.scm.connection}/${project.artifactId}</connection>
...
/scm>
Where parentPOM is a made-up symbol denoting an upward search for the pom property that follows (scm.connection).

So, how about the following suggestion:
The Super POM contains this kind of definition for all URLs where this rule applies today. When the effective POM
is computed for a sub-project it uses the "closest" url definition that contains the symbol parentPOM. If none is
found expect the def in super pom, this one is used and the rule applies as it always has.

On the other hand, if one decides to put an url expression containing parentPOM into a POM of type 'pom',
then there is a new definition and will be used. That means, we have a way to define how sub-project urls should
be constructed. I would be delighted if I could define an expression like
${parentPOM.scm.connection}/${project.name}/trunk

There is a residual problem, however: I cannot define both an url expansion expression and an actual url expression
that is intended to be used in sub-projects. The easiest solution, is just to have two organization poms, the top-most
pom contains the url expansion expressions (overriding the rule from the super pom) and the one beneath is the
original org pom, containing actual urls that will be used in the expansions further down.

I'm convinced there are other more elegant solutions. However, the suggestion above would be fairly easy to implement
without breaking existing code and poms (or require a POM version increment), but still provide a way for org-pom
designers to tweak the url expansions the way they want.

Comments / Objections ???

I would strongly argue for a change to the POM to be able to turn this off globally (not just for site URLs). I'd prefer for that to be the default (I think the current behavior violates the principle of least surprise), but that's water under the bridge in terms of compatibility at this point. We really need a way of turning this off though--I really think it will lead to simpler POMs.