Forrest (copyless-merged) bugs (was Re: No joy... )

[Nicola Ken Barozzi <ni...@apache.org>]

Ok, we have our first detailed bug report after the copyless branch 
merge. Thanks, Adam! :-)

Adam R. B. Jack wrote:
 > 1) I don't think Forrest likes directories called 'api'. Confuses the
 > bejeebez out of it.

Ugh, this is not that nice. It shouold go away with locationmaps in the 
next releases, but for now renaming the dir or changing the cli xconf 
will do the trick.

...
>>>2) I don't think Forrest likes pages called 'todo.xml' (even when not in
>>> the root).
>>
>>You're right.  Delet the reference to it in sitemap.xmap to work around
>>that.
> 
> Could Forrest validate against such things, or give a nice warning/error
> message or something?

It should, yes. In fact yours is the first bug report for this, so we 
hadn't thought of it much before. Usually we have forrest to generate 
sites that users start from the template, not heavily pregenerated sites 
like Gump (that we *have* to support for DOCO).

What we should do:

- deprecate status.xml, todo.xml, etc handling by filename
- insert the recognition of them by DTD
- do a check in Ant that suggests to add a DTD to these files if
   it finds them

>>>3) I don't think 'forrest' (batch) and 'forrest run' work comparably. I
>>>ran
>>>both and got:
>>>3.1) No menus on my batch pages
>>>3.2) Different sized fonts
>>>3.3) Different 'corners' (on tabs)
>>
>>What skin?  I think some are currently broken.  todo: we need to check all
>>skins before a release candidate.
>
> Krysalis. I think it is likely me, due to my site.xml/tabs.xml or something,
> but I get a site with "forrest run" (as does somebody on same xdocs on older
> Forrest) but I get oddities w/ batch "forrest".

You mean that forrest run works ok and the batch one doesn't.
I know that the rounded corners are currently *not* generated with batch 
forrest - bug - but probably the last fix on the skins also broke the 
menus. Will have to check.

[Taken from Re: Build.sh and build.bat creating just JAR]

Adam R. B. Jack wrote:

> I put content that I do NOT ask Forrest to generate into ./content 
> [e.g. ./content/ant/rss.xml and ./content/ant/atom.xml] and the 
> content I DO ask Forrest to generate into ./content/xdocs [e.g. 
> ./content/xdocs/ant/index.xml.] Forrest transfers the things I 
> produce the rss.xml atom.xml are mine, not from Forrest) and it
> generates index.html giving me:
> 
> {site}/ant/rss.xml {site}/ant/atom.xml and {site}/ant/index.html

Ok, so it *does* generate index.html.

> What I am saying is the transfer occurs (I get the first two) but not
> the last one. 

You mean that it does not transfer index.*xml* but it correctly 
generates index.html?

If so, this is correct and it has always done so. (a)

If you don't get a correctly generated index.htmlwe have a problem. (b)

> As this is an ant copy (I think), that makes some sense.

Case (a) or (b)?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Forrest (copyless-merged) bugs (was Re: No joy... )

[Nicola Ken Barozzi <ni...@apache.org>]

Adam R. B. Jack wrote:
 > Nicola Ken Barozzi:
...
>>You mean that it does not transfer index.*xml* but it correctly
>>generates index.html?
>>
>>If so, this is correct and it has always done so. (a)
>>
>>If you don't get a correctly generated index.htmlwe have a problem. (b)
>>
>>>As this is an ant copy (I think), that makes some sense.
>>
>>Case (a) or (b)?
> 
> It used to be (a) with previous Forrest. It is currently (b) 'cos I was
> passing -Dproject.site-dir on the command line and the transfer/copy (of
> rss.xml) occurs to there, but the generation/transfer occurs to where
> project.site-dir is set in the forrest.property files. The things go to two
> places, not one. This is the command line -D issue you know exists. Any
> decision on if you'll fix it or not? 

I'll fix it(when I come back from my small vacation in Rimini next week :-).

> If not, I can deprecate Gump calling
> Forrest (might do so anyway) and only allow Gump to write xdocs into a
> Forrest webapp (nicer performance).

Probably you would want to do it in any case, so that it will "force" 
users to use 'forrest run' to see it locally and to install forrest 
webapp to see it on the website.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: Forrest (copyless-merged) bugs (was Re: No joy... )

["Adam R. B. Jack" <aj...@trysybase.com>]

> Adam R. B. Jack wrote:
>
> > I put content that I do NOT ask Forrest to generate into ./content
> > [e.g. ./content/ant/rss.xml and ./content/ant/atom.xml] and the
> > content I DO ask Forrest to generate into ./content/xdocs [e.g.
> > ./content/xdocs/ant/index.xml.] Forrest transfers the things I
> > produce the rss.xml atom.xml are mine, not from Forrest) and it
> > generates index.html giving me:
> >
> > {site}/ant/rss.xml {site}/ant/atom.xml and {site}/ant/index.html
>
> Ok, so it *does* generate index.html.
>
> > What I am saying is the transfer occurs (I get the first two) but not
> > the last one.
>
> You mean that it does not transfer index.*xml* but it correctly
> generates index.html?
>
> If so, this is correct and it has always done so. (a)
>
> If you don't get a correctly generated index.htmlwe have a problem. (b)
>
> > As this is an ant copy (I think), that makes some sense.
>
> Case (a) or (b)?

It used to be (a) with previous Forrest. It is currently (b) 'cos I was
passing -Dproject.site-dir on the command line and the transfer/copy (of
rss.xml) occurs to there, but the generation/transfer occurs to where
project.site-dir is set in the forrest.property files. The things go to two
places, not one. This is the command line -D issue you know exists. Any
decision on if you'll fix it or not? If not, I can deprecate Gump calling
Forrest (might do so anyway) and only allow Gump to write xdocs into a
Forrest webapp (nicer performance).

regards,

Adam