forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Upayavira">
Subject Re: residuals of MIME type bug ?
Date Thu, 26 Jun 2003 07:43:12 GMT
There are quite a lot of new features in the Cocoon CLI that Forrest isn't using, for 
example the option to switch off mime-type checking, and to only scan pages once 
(i.e. not using the link-view) to follow links.

I believe there are still some problems with these new features in the CLI, but it 
should be possible to fix these. [For example, links being gathered on pipelines 
referenced via cocoon: protocol - I've found why, but not yet fixed it].

Is anyone interested in looking into how to upgrade Forrest to use these new 

I think that doing this would stand a chance of resolving all of Luc's problems, and 
give me some people to do some solid debugging of the CLI.

Any takers?

Regards, Upayavira

On 25 Jun 2003 at 8:28, MAISONOBE Luc wrote:

> Hello,
> I have updated my forrest source tree yesterday evening (european
> time) including the new cocoon jar.
> This has solved the file.extnull problem I had encountered like
> everyone else, and also partly solved my src/content/file.xml problems
> (those files were parsed and slightly modified despite they are not in
> the xdocs sub-directory). The files are now correctly copied
> untouched.
> The remaining problems I see are :
>    - a single java source file that should also be copied as is has
>      its name changed from to
>      (before the cocoon change, it was renamed with the .text suffix
>       rather than .txt so I think this is still related to the same
>       bug)
>    - a compressed PostScript file is copied twice, once as is and
>      another time in decompressed form (with the .gz suffix removed)
>    - spurious error messages appear during site generation:
>      Despite the files are copied near the beginning of forrest run, I
>      get the following error messages later on (and the files are
>      listed in the brokenlist.txt file). I noticed also that one of my
>      xml file did generate an error message and was not listed. I did
>      not understand why this one was different from the other ones.
> ------------------------------------------------------------------
>          ...lots of stuff omitted ...
>   * [0] skin/images/valid-html401.png
>   * [41] downloads.html
>   * [0]
> -> [broken page] software/rkcheck/HighamHall.xml <-
>       /home/luc/
>       ocs/software/rkcheck/HighamHall.xml (No such file or director y)
>          ...lots of stuff omitted ...
> ------------------------------------------------------------------
>      It seems as if due to the .xml suffix, some part of the
>      process expect the file to really live in the xdocs directory,
>      and logically doesn't find them here. I suspect my file names are
>      recognized by two different rules, one based on their directory
>      (not in xdocs), and another one based on their suffix (*.xml).
>      The first rule working correctly for these file types now, and
>      the other rule failing. If this is the case, a simple correction
>      would be to extend the pattern to something like */xdocs/*.xml or
>      similar. Does it make sense ?
> I can try to look at this problem by myself, could you advise me were
> to start (sitemap.xmap only ?). I don't think I can handle the first
> two problems though.
>                                    Luc

View raw message