|
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 My solution, the method assembleDistributionInheritence(...) should be modified like this: ... } 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:
A temporary solution might be to do the same thing using well-documented POM properties, eg
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. 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
[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 So, how about the following suggestion: On the other hand, if one decides to put an url expression containing parentPOM into a POM of type 'pom', There is a residual problem, however: I cannot define both an url expansion expression and an actual url expression I'm convinced there are other more elegant solutions. However, the suggestion above would be fairly easy to implement Comments / Objections ??? Note, dission on dev list: http://www.nabble.com/Comments---Ideas-for-MNG-3244-td15808822s177.html#a15808822
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 really have problems convincing my colleagues to switch to Maven when such a bug is not fixed for month.