Forrest
  1. Forrest
  2. FOR-156

broken links building forrest site

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.6
    • Fix Version/s: 0.6
    • Component/s: Launch 'forrest'
    • Labels:
      None

      Description

      I removed the forrest site's cli.xconf since it's only significant differences from the default cli.xconf were ignoring ext:** and site:** which we didn't want anyway.

      Now there are many broken links reported when building the site. However, it seems that there are no broken links on the generated pages.

      So there's a bug in the CLI I think.

        Issue Links

          Activity

          Hide
          Nicola Ken Barozzi added a comment -
          Now CSS files are parsed internally, so that the urls are included in the static site generation.
          Show
          Nicola Ken Barozzi added a comment - Now CSS files are parsed internally, so that the urls are included in the static site generation.
          Hide
          Dave Brondsema added a comment -
          I still get 28 broken links
          Show
          Dave Brondsema added a comment - I still get 28 broken links
          Hide
          Nicola Ken Barozzi added a comment -
          I don't :-?

          I have just done a fresh seed, then changed the skin to forrest-site in forrest.properties, then done "forrest".

             BUILD SUCCESSFUL
             Total time: 56 seconds

          What are the broken links you get?
          Are you sure your Forrest is up to date?

          I just updated mine, so it /should/ be ok...
          Show
          Nicola Ken Barozzi added a comment - I don't :-? I have just done a fresh seed, then changed the skin to forrest-site in forrest.properties, then done "forrest".    BUILD SUCCESSFUL    Total time: 56 seconds What are the broken links you get? Are you sure your Forrest is up to date? I just updated mine, so it /should/ be ok...
          Hide
          Dave Brondsema added a comment -
          Forrest's own documentation has broken links, not forrest seed.
          Show
          Dave Brondsema added a comment - Forrest's own documentation has broken links, not forrest seed.
          Hide
          Nicola Ken Barozzi added a comment -
          Oops, I think I wrote on the wrong bug... probably because the right bug was never entered 8-)
          Show
          Nicola Ken Barozzi added a comment - Oops, I think I wrote on the wrong bug... probably because the right bug was never entered 8-)
          Hide
          Nicola Ken Barozzi added a comment -
          I don't understand why we should not ignore ext:** and site:** links.

          These urls are *not* to be traversed, only the resulting resolved links are to be used, so I don't understand why we should not exclude them.

          They will *always* be broken, as the Cocoon source resolver does not have any notion of these urls.

          IMO just putting in the ignore will fix things well and without bad side effects. In fact, as you have noted, the site is all well, right?
          Show
          Nicola Ken Barozzi added a comment - I don't understand why we should not ignore ext:** and site:** links. These urls are *not* to be traversed, only the resulting resolved links are to be used, so I don't understand why we should not exclude them. They will *always* be broken, as the Cocoon source resolver does not have any notion of these urls. IMO just putting in the ignore will fix things well and without bad side effects. In fact, as you have noted, the site is all well, right?
          Hide
          Jeff Turner added a comment -
          Nicola,

          In normal use, why would Cocoon's CLI ever encounter untranslated site: and ext: URLs, except if the author mistyped a link, or forgot to add a site.xml entry? In that case, it is an error, and the CLI should report it as such instead of quietly ignoring what is a broken link.

          The reason Forrest's own site requires site: and ext: to be ignored is because in sitemap-ref.xml, we *deliberately* link to an untranslated index.xml page:

          http://xml.apache.org/forrest/index.xml

          This is where the ignorable site: and ext: links in Forrest's documentation come from. For everyone else, an untranslated site: or ext: URL is an error and should be reported as such.
          Show
          Jeff Turner added a comment - Nicola, In normal use, why would Cocoon's CLI ever encounter untranslated site: and ext: URLs, except if the author mistyped a link, or forgot to add a site.xml entry? In that case, it is an error, and the CLI should report it as such instead of quietly ignoring what is a broken link. The reason Forrest's own site requires site: and ext: to be ignored is because in sitemap-ref.xml, we *deliberately* link to an untranslated index.xml page: http://xml.apache.org/forrest/index.xml This is where the ignorable site: and ext: links in Forrest's documentation come from. For everyone else, an untranslated site: or ext: URL is an error and should be reported as such.
          Hide
          Dave Brondsema added a comment -
          So we should ignore **/*.xml, right? And then the only broken links reported would be truly invalid ones?
          Show
          Dave Brondsema added a comment - So we should ignore **/*.xml, right? And then the only broken links reported would be truly invalid ones?
          Hide
          Jeff Turner added a comment -
          I'm not sure why ignoring **/*.xml would help? It would break Forrest's own site, because we *want* to link to index.xml. Most users don't link to *.xml, but I'm sure some do; eg. with a subsitemap generating RSS for certain pages.
          Show
          Jeff Turner added a comment - I'm not sure why ignoring **/*.xml would help? It would break Forrest's own site, because we *want* to link to index.xml. Most users don't link to *.xml, but I'm sure some do; eg. with a subsitemap generating RSS for certain pages.
          Hide
          Nicola Ken Barozzi added a comment -
          <jefft>In normal use, why would Cocoon's CLI ever encounter untranslated site: and ext: URLs </jefft>

          Good question.

          Now it does, as *all* links that pass in any cocoon pipeline are traversed now.
          For example, in a single pipeline I get the links from the css in chaperon and then serialize to text; well, these links are traversed.

          <jefft> except if the author mistyped a link, or forgot to add a site.xml entry? In that case, it is an error, and the CLI should report it as such instead of quietly ignoring what is a broken link. </jefft>

          The link would still be reported as broken IIUC, as this would come out in the translation or when they are outputted already resolved.

          Basically, assing an exclude we are doing exactly what the CLI does before, as it does not traverse them. What makes this exclusion different from the previous implicit exclusion?
          Show
          Nicola Ken Barozzi added a comment - <jefft>In normal use, why would Cocoon's CLI ever encounter untranslated site: and ext: URLs </jefft> Good question. Now it does, as *all* links that pass in any cocoon pipeline are traversed now. For example, in a single pipeline I get the links from the css in chaperon and then serialize to text; well, these links are traversed. <jefft> except if the author mistyped a link, or forgot to add a site.xml entry? In that case, it is an error, and the CLI should report it as such instead of quietly ignoring what is a broken link. </jefft> The link would still be reported as broken IIUC, as this would come out in the translation or when they are outputted already resolved. Basically, assing an exclude we are doing exactly what the CLI does before, as it does not traverse them. What makes this exclusion different from the previous implicit exclusion?
          Hide
          Nicola Ken Barozzi added a comment -
          Now I understand. When a link that is not in site.xml is found, the link is outputted as-is. So we need to have Cocoon traverse *that* link (not the original one in the xml) to spit out the right error.

          We have a catch22, as it traverses now both per CLI design, and a simple exclusion cannot discriminate between the two.

          What about having the linkmap system change inexistant links in the output? Something like:

            site:xmy-project -> error:site:my-project

          In this way we can exclude error:**
          Show
          Nicola Ken Barozzi added a comment - Now I understand. When a link that is not in site.xml is found, the link is outputted as-is. So we need to have Cocoon traverse *that* link (not the original one in the xml) to spit out the right error. We have a catch22, as it traverses now both per CLI design, and a simple exclusion cannot discriminate between the two. What about having the linkmap system change inexistant links in the output? Something like:   site:xmy-project -> error:site:my-project In this way we can exclude error:**
          Hide
          Jeff Turner added a comment -
          Okay, then I'm lost :) As long as something breaks when I write site:foo and <foo> doesn't exist in site.xml, I'm happy.
          Show
          Jeff Turner added a comment - Okay, then I'm lost :) As long as something breaks when I write site:foo and <foo> doesn't exist in site.xml, I'm happy.
          Hide
          Nicola Ken Barozzi added a comment -
          Should be fixed now, please check.
          Show
          Nicola Ken Barozzi added a comment - Should be fixed now, please check.

            People

            • Assignee:
              Nicola Ken Barozzi
              Reporter:
              Dave Brondsema
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development