No way to avoid adding artifactId to site urls

Hello,

I have the same problem with scm URLs which have the artifactId appended too. That's extremely disturbing because we don't want to nest projects with an scm repository (FWIW it's svn).

We prefer a flat structure even if we have parent-child dependancies. And of course, we don't want to duplicate the <scm> section in each and every POM (which we currently have to do).

I think the priority of this bug should be more important.

Is there a way we can help with the issue?

Thanks

We actually found a workaround for this problem in our particular usecase.

The main distributionManagement section in our parent-pom has the url ready to be appended to by child poms, and the parent-pom also has a profile which overrides it just for that one pom; thus:

  <profiles>
    <profile>
      <id>deploying-base-pom-itself</id>
      <activation>
        <file>
          <exists>THIS-IS-base-pom</exists>
        </file>
      </activation>
      <distributionManagement>
        <site>
          <id>mx-release</id>
          <url>scpexe://host/blah/base-pom</url>
        </site>
      </distributionManagement>
    </profile>
  </profiles>

This profile is then enabled for the base pom by creating a file entitled THIS-IS-base-pom.

I think this might also work for the scm url.

Obviously this becomes a less useful solution for deeper project heirarchies, but it works pretty well for us.

Good idea, thanks

Although I still need a proper fix because we usually have two levels:

• our "enterprise" pom
• an "application head" containing all the modules an dinheritting from the "enterprise" pom
• the application modules inheritting from the "application head"

Anyway, thanks for the idea. Maybe I can refine it to use our two levels (if the names of the flag files are well defined it may be simple enough to put everything in the "enterprise" pom).

UPDATE: it does not work... I cannot put an <scm> within a <profile>

I would like to add a plea for this behaviour to be modified - we too have a similar 3 level pom inheritance hierarchy, and it is irritating to have to specify the URLs in the final level when the root is specified in the top level because the intermedate level is automactically inserted. I think that the problems come about here because there is not a clear distinction made between pom inhertance and project aggregation - typically if a project only inherits from another project then the values should only be inherited, without modification - it a project is an aggregated child as well, then various URLs can have artifactIds automatically added to the end.

Even with this modification to behaviour I would also support the suggestion above that automatic appending of artifactId only occurs when the URL ends explictly with a "/" - this allows for more complex URL layouts to be specified in the root POM with the use of variables such as the

<url>scpexe://host/blah/$

/$

</url>

which I think is a rather commonly desired layout.

Is this really an issue for the Site Plugin? The comments seem to indicate that it has to do with how maven-model works (or doesn't work) with properties.

correct. This requires a model change - probably by a combination of two things:

1. the facility for the site and reporting plugins to intelligently create a multi-module site map with equivalent functionality to the current URL extension
2. removal of the inheritance rules (or site elements) from the POM in a new model version

We can keep this issue to the latter

It seems that the problem described here is responsible for my current problem when trying to use the maven-release-plugin ...
I linked the following issue: MRELEASE-331

Remove the inheritance rules but provide a maven configured variable $

or something that will becomes "/parent-parent/parent" in deepest level of a 3 level project. The super POM will be an empty string. The mid-level will be "/parent-parent". Now users get the best of both worlds without being chained to the convention.