Maven Site Plugin
  1. Maven Site Plugin
  2. MSITE-159

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

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3, 3.0
    • Component/s: relative links
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          Hide
          skaze added a comment -

          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.

          Show
          skaze added a comment - 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.
          Hide
          kay added a comment -

          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?

          Show
          kay added a comment - 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?
          Hide
          skaze added a comment - - 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

          Show
          skaze added a comment - - 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
          Hide
          Ted Husted added a comment -

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

          Show
          Ted Husted added a comment - If the configuration option said "render absolute URLs absolute," then yes, that would be helpful.
          Hide
          skaze added a comment -

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

          Show
          skaze added a comment - 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 ..
          Hide
          Ramon Liu added a comment -

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

          Show
          Ramon Liu added a comment - I think it should work what one would expect. In HTML there is absolute and relative. Don't translate it.
          Hide
          kay added a comment -

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

          Show
          kay added a comment - (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.
          Hide
          Philip May added a comment -

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

          Show
          Philip May added a comment - 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...
          Hide
          Paul Davis added a comment -

          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.

          Show
          Paul Davis added a comment - 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.
          Hide
          M. Rohrmoser added a comment -

          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.

          Show
          M. Rohrmoser added a comment - 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.
          Hide
          M. Rohrmoser added a comment -

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

          Show
          M. Rohrmoser added a comment - Sadly, the workaround above will not work with Firefox 3.0 - see https://bugzilla.mozilla.org/show_bug.cgi?id=43659
          Hide
          kay added a comment -

          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.

          Show
          kay added a comment - 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.
          Hide
          Robert Burrell Donkin added a comment -

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

          Show
          Robert Burrell Donkin added a comment - Introducing buggy URL rewriting code just because some Maven users don't understand URLs is a poor design choice.
          Hide
          Dmitry Grigoriev added a comment -

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

          Show
          Dmitry Grigoriev added a comment - 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"/>
          Hide
          Lukas Theussl added a comment -

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

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

            People

            • Assignee:
              Lukas Theussl
              Reporter:
              Ted Husted
            • Votes:
              22 Vote for this issue
              Watchers:
              19 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development