broken links building forrest site

• Key: FOR-156
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Nicola Ken Barozzi
• Reporter: Dave Brondsema
• Component/s: Launch 'forrest'
• Affects Version/s: 0.6
• Fix Version/s: 0.6

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.

Comments

[Nicola Ken Barozzi]

Now CSS files are parsed internally, so that the urls are included in the static site generation.

[Dave Brondsema]

I still get 28 broken links

[Nicola Ken Barozzi]

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

[Dave Brondsema]

Forrest's own documentation has broken links, not forrest seed.

[Nicola Ken Barozzi]

Oops, I think I wrote on the wrong bug... probably because the right bug was never entered 8-)

[Nicola Ken Barozzi]

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?

[Jeff Turner]

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.

[Dave Brondsema]

So we should ignore **/*.xml, right? And then the only broken links reported would be truly invalid ones?

[Jeff Turner]

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.

[Nicola Ken Barozzi]

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

[Nicola Ken Barozzi]

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:**

[Jeff Turner]

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.

[Nicola Ken Barozzi]

Should be fixed now, please check.