Maven 2.x and 3.x Site Plugin

relative paths were partially supported in beta-4 however the logic did not resolve sibling paths with a common ancestor. Maybe offline generation (i.e. preserving URLs) should be a command line option as relatives make it possible to do many things such as stage a web site and check that links are valid BEFORE deployment to the target location.

Moreover the current behaviour of the site generation leads to the following annoying issue:
pom:
<url>https://bla.mycomp.nl</url>
<distributionManagement><site><url>scp://mycomp.nl/home/groups/bla/htdocs/site</url></site></distributionManagement>
(where the project url is mapped to the htdocs directory)
site.xml:
<menu name="Docs"><item name="Document share" href="https://bla.mycomp.nl/docs"/>

In this case, the it will create a relative link to href="docs". but since my site gets deployed in subdirectory ./site it will point erroneously to ./site/docs

Now you can argue that the project-url is meant to point to the root of the site deployment location.
But in my opinion absolute paths should stay absolute. Isn't that the reason why you define them absolute, because you want to overrule the relation with the deployment url?

IMHO a project.URL is supposed to point to the web accessible location for that project and thus yes there is tight coupling between the distroManagement.site.url and the project.URL. If one wants to redirect/map via web mechanism the project.URL to some other web location then that's fine too. (i.e. redirect your htdocs requests to htdocs/site)

Re isnt that why you define them as absolute? Well yes but also not really, a project's URL is absolute as it is its published external web address accessible from anywhere for that artifact. I can depend on your project and will want to link to its web materials. If you made your sub-modules use explicitly defined relative URLs then they would never be accessible to anyone other than your related site pages (ie parent/children).

Re offline - We find it easier to generate our offline docs using these auto-generated relative URLs, we get a sompletely self referential site and the browser doesnt try and jump online all the time.

I expect the real answer to these 'i dont like', 'i do like' issues with relative URLs is to make it a configuration option

If the configuration option said "render absolute URLs absolute," then yes, that would be helpful.

I think something along the lines of 'convert URLs to relative URLs where possible' is sensible.

Note that even relatives can be converted into better relatives. i.e.

foo/bar/../../foo/bar/../ is the same as ..

I think it should work what one would expect. In HTML there is absolute and relative. Don't translate it.

(John, sorry for my late reaction.)

You are right: the internal references of the generated site should work wherever its build. Thats why the url's should be relative there.

BUT: in the example above the point to use an absolute url is, that it refers to an EXTERNAL resource (https://bla.mycomp.nl/docs). Since this resource happens to have the same base url than the site deployment url, maven thinks that it should be treated as relative.
I agree with Ramon, that maven should not override well established conventions here just to correct wrong configuration (people using absolute url's in the site descriptors where they should use relatives).

Also I did not say that the project's main site url should be relative.

What would the configuration option be here? 'interpret ALL absolute url's with the same base-url as the site root as relative url's' ?

Correct me if I didn't get what you commented.

This bug is realy ugly cause this way it's very difficult to have a sourceforge project site build by maven...
With a Sorceforge project you have to link to them...

Best would be an option to specify. ESPECIALLY for external links.
External links should never get converted to relative links, which appears to happen arbitrarily.

Workaround: replace one of the characters of the external/absolute URL with it's url-encoded form, e.g. a . (dot) within the servername with %2e.

This seems to prevent substitution.

Sadly, the workaround above will not work with Firefox 3.0 - see https://bugzilla.mozilla.org/show_bug.cgi?id=43659

Hmmm. nothing happend yet.

I think this is really a design decision. Although in my eyes a faulty one.
Maven just assumes, that the location of the site generated by maven should always be the projects main site (specified in the pom as <project><url> )
As mentioned above, there are legitime cases where this is not true. And technically it would be a perfect solution just not to intervent by automagically truncate absolute url's.

It would be nice someone responsible at maven could motivate the current policy.

Introducing buggy URL rewriting code just because some Maven users don't understand URLs is a poor design choice.

Workaround mentioned by M. Rohrmoser does not work even in URL path component. I'd like to have just a couple of attributes for few particular menu items:

<item name="..." href="..." rewrite="false" external="true"/>

Fixed with MSHARED-189 and r1076195.
There is now a parameter <relativizeDecorationLinks> (default value: true) that can be used to switch off relativization.