[#MSITE-159] Absolute URI rendered as relative URI if absolute URI related to domain of POM URI

Maven 2.x Site Plugin

Absolute URI rendered as relative URI if absolute URI related to domain of POM URI

Created: 12/Jul/06 09:56 AM Updated: 09/Apr/09 11:50 PM

Component/s:

relative links

Affects Version/s:

None

Fix Version/s:

None

Time Tracking:

Not Specified

Issue Links:

Duplicate

This issue is duplicated by:

~~MSITE-269~~ Urls rewritten when they contain the project urls' hostname

~~MSITE-254~~ Error when using an absolute URL in a menu item in site.xml

~~MSITE-197~~ poweredBy Logo links don't work

~~MSITE-229~~ Links in site.xml get translated to ../../../

Description

« Hide

Under site-beta5

if the POM references a URI like

<url>http://struts.apache.org</url>

absolute URLs used in the site.xml file are converted to relative references.

For example a reference to to "http://struts.apache.org/1.x" becomes "1.x", and a reference to
just "http://struts.apache.org" becomes an empty string.

If the documentation is being used offline, there are many cases when we want to refer people back to the website, to be sure the current information is used. The best use case is a download page that determines the mirror via CGI.

Another use case is referring to a sister site in the domain, that might refer to another version. If used locally, the other site might not be in the relative location.

Switching back to beta4 cures the behavior, and absolute URIs remain absolute, as expected.

All

Comments

Work Log

Change History

Sort Order:

[ Permalink | « Hide ]

John Allen added a comment - 05/Nov/06 12:40 PM

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.

[ Permalink | « Hide ]

Kay Grosskop added a comment - 21/Nov/06 09:34 AM

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?

[ Permalink | « Hide ]

John Allen added a comment - 23/Jul/07 12:43 PM - edited

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

[ Permalink | « Hide ]

Ted Husted added a comment - 23/Jul/07 03:09 PM

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

[ Permalink | « Hide ]

John Allen added a comment - 26/Jul/07 06:15 AM

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

[ Permalink | « Hide ]

Ramon Havermans added a comment - 15/Feb/08 03:10 AM

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

[ Permalink | « Hide ]

Kay Grosskop added a comment - 15/Feb/08 03:49 AM

(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.

[ Permalink | « Hide ]

Philip May added a comment - 09/Apr/08 06:24 AM

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

[ Permalink | « Hide ]

Paul Davis added a comment - 16/Apr/08 07:12 PM

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.

[ Permalink | « Hide ]

M. Rohrmoser added a comment - 08/Jul/08 02:23 PM

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.

[ Permalink | « Hide ]

M. Rohrmoser added a comment - 17/Jul/08 09:30 AM

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

[ Permalink | « Hide ]

Kay Grosskop added a comment - 09/Apr/09 11:50 PM

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.