Maven 2 & 3

I hereby kindly ask you to fix the bug.

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

The issue origins seems to be the DefaultModelInheritanceAssembler.class wich automatically adds the parents artifactId no matter what.
According to the site-plugin in documentation the inheritance of the parents artifactId can enabled by adding a trailing / to the url.
But the InheritanceModel doesnt apply this rule.

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( "/" ) )

}
}
...

Here is a fix for Maven 2.0.8 with tests.

Thanks for the patch. I updated it to handle \ in the path and another small issue I found while testing.

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

Brian, we all seem to want this fix, but don't want to break existing behaviour (however bizarre it may be).

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.

Site patch is applied.

remember that the site distro URL and the project URL are related. If you add the documented but missing feature of being '/' aware for one of them (i.e. as you have with this patch and its handling of site distro url) you will need to add the same feature to the project url assembly.

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}

After playing with some patch some more i came across another problem beyond the one mentioned above. You need to ensure that the trailing slash is propagated to the child projects URLs (distroManagement.site.url and project.url) otherwise the logic based upon the presence of the trailing slash stop working. i.e. if you call appendPaths you must ensure that the resulting path ends with a '/'.

Will this also be implemented for the SCM URLs and the various other places where the artifactid is automatically appended? Because this bug here supercedes MNG-2290, which supercedes MNG-2219, which is about SCM URLs. And can someone, please, document that? Because a guide is not a place to put such an important piece of information. Maybe the right place would be the docs for the pom.xml structure?

[I sent this comment to the list, without any repsonse, so I decided to put them here - where they belong]

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

There isn't a way that i know of to refer to a value in the parent pom. This would require defining a whole new property and is more than I think we want to do in 2.0.x.

Note, dission on dev list: http://www.nabble.com/Comments---Ideas-for-MNG-3244-td15808822s177.html#a15808822

There seems to be no solution available to fix this in 2.0.x

I'm fairly new to Maven, but I find the default behavior for all URLs very confusing. I understand the desired behavior, but many projects are just not arranged like the default behavior implies. The same URL alteration happens for SCM urls, the overall project URL, etc. I had initially created a corporate parent POM that I had hoped could work about 85% of our SVN repos by default, but I will have to override every one in the actual POM for each project (the suggested workaround).

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.

I'm going to summarize all that this peculiar functionality touches upon, some of which can be traced in the issue links above, in order to justify my attached patch and hope for its consensus adoption.

There's a Maven 1-ey method in DefaultModelInheritanceAssembler, appendPath(..), that may append a child path relative to a parent (project) path and this path becomes the returned URL. In practice, this method is called upon from three places in this inheritance-assembling class: all of <scm>, the <url> inside <site> inside <distributionManagement>, and the top-level <url>, where the parent has a value and the child doesn't. And in each case, the child path is its <artifactId>. The boolean param that determines whether to "append child to parent," AFAICT, is hard-coded to true in each of these cases and, hence, no matter what the inherited value may be, the child path (artifactId) is appended and for most inheritance schemes, you see a strange reflective..artifact..of the artifactId tacked on the end of these resolved URLs. Again, it all sounds very Maven 1-ey, where children are logically inside parent or relative to it.

Most inheritance schemes, as I've said, for these values are of this flavor: the inherited child value is http://www.foo.com/etc/${project.artifactId} – according to my following the bug trails. Rather than rewrite this aspect of the model, as Brett Porter suggested [1], my proposed patch quietly inserts a check for a certain condition and, if present, follows different inheritance logic. My aims were:

1. Non-disruptive insertion - if present, do this, else keep the status quo.
2. Cover 90% (or better) of the cases - there may be other fringe (inheritance) cases my patch does not address but I think I've landed on the majority and, with #1 in mind, it does no worse for those cases.

So my patch is basically this: if the child has no value and the parent does (for those POM elements mentioned), and if the parent value ends with a Maven expression (i.e. ${blah}), then child value = parent value, otherwise, as you were. (Paul Harrison suggested [2] the choice of the algorithm be the presence of '/' at the end of the parent value but I think the "ends with Maven expression" is a more direct approach.)

My patch includes new units and has been utilized in a full rebuild of 2.2.2-RC1-SNAPSHOT successfully. I look forward to hearing everyone's feedback.

• Steven

[1] http://jira.codehaus.org/browse/MNG-4508?focusedCommentId=204629&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_204629

[2] http://jira.codehaus.org/browse/MNG-4508?focusedCommentId=174940&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_174940

patch by Steven MountJoy

My company has a flat SVN structure, with trunk/, tags/ and branches/ folders in every project. e.g.

.../corporate-pom/trunk/
.......................pom.xml
................./tags/
................./branches/

.../project1/trunk/
..................pom.xml
............/tags/
............/branches/

We were hoping to factor out scm, site and nexus urls from all of our projects into a corporate pom. Due to this bug though, maven is appending artifactid again after trunk/ in inherited urls, which doesn't make sense for this structure. So basically this bug will prevent us from factoring out most of the configuration, and we'll have to copy/paste the same url template into every pom.

Can we consider fixing this bug for maven 2.x again?

..Edited to remove a suggestion which has some problems on closer examination.

@Steven MountJoy- I looked at that patch, and I think it would improve the situation for some people, but for us it's not going to fix the broken handling of our scm urls because we put our variables in the middle of the urls unfortunately, and we put "/trunk" at the end.

@all
Perhaps looking for patterns in urls is not the way to go to decide whether or not to apply the fixed logic.

How about we apply the fix if property "mng-3244-append-artifactId-to-parent-urls" is set to "false" (as William Ferguson above suggested 2.5 years ago), otherwise we apply existing behaviour?

I can't see any way that this could break existing behaviour.

Since I've experiencing issues on this as well, I've been thinking that referencing i.e. project.version in a parent pom (to the parent's version) should be possible.
I might not see a certain UC or already implemented behaviour, but wouldn't this be possible (and still be backwards compatible) by adding one of two behaviours:

1. A way to specify properties that are resolved to the correct version (from the pom that they're in) either at install time or at the time the effective pom is generated. A proposal on this option would be to use i.e. #{property} or maybe $[property]
I think that this might even be possible in a Maven plugin, but there will be a problem with backing up the pom first then as well. If there's a way to hook into the effective pom generation it can be done cleanly though without touching the pom on disk.

2. A way to specify a certain parent in the hierarchy, though this would require a model change. It would then be possible to request a certain parent, i.e. by doing ${project.parent.someParentGroup.someParentId}

Personally I like #1 the most, though #2 is probably the most powerful. Both will of course require a substantial amount of work, but I expect that #2 will require a lot more than #1.

ps. just wondering: are votes counted together from all related issues? If so I might vote on them all

It's sad to see that this issue hasn't been fixed in all these years. People really need it.

I ended up specifying following snippet in each and every child pom:

<distributionManagement>
  <!-- repositories inherited-->
  <site>
    <id>${distributionManagement.site.id}</id>
    <url>${distributionManagement.site.url}</url>
  </site>
</distributionManagement>

Whereas the same snippet is defined in the parent pom (including repositories of course!) and this parent pom also defines the referenced properties:

<distributionManagement.site.id>someid</distributionManagement.site.id>
<distributionManagement.site.url>scp://somehost.example.org/u/admin/maven/site/${project.artifactId}</distributionManagement.site.url>

I needed to do the same for project.url and all the URLs in project.scm.

It's a quite cumbersome workaround but this way I can use a "dumb" copy and paste approach when creating new child poms - without needing to remember to append the artifactIds! At the the same time I can just release the parent pom as usual, including correct site deployment.