You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by hepabolu <he...@gmail.com> on 2005/11/09 16:30:43 UTC

Re: [DOCS] Building for release - update

sorry for duplicating Ross' effort. I only know understand what he meant 
by "removing the documentation name is not the solution".

I now also realise what happened and what the rationale was behind the 
way it is currently set up in Daisy:

the main menu bar suggests that there are sub sections: About, 
Documentation, Community etc. I wanted to keep that division so I 
created the "folders" About, Documentation, Community etc. I focused 
more on the appearance of the menu on the left than on the urls. When 
there was a discrepancy, I choose the menu above the url.

So, I can either remove the "headers" like About and Documentation and 
they have to be added in the daisy-to-forrest conversion, or we have to 
settle for a slightly adjusted url space.

When removing the xdocs from the repository I left the original book.xml 
and other relative files in for reference of these headers.

So from my POV there is an inconsistency between what the menu suggest 
and the urls reflect in the ORIGINAL site. I have tried to fix that in 
the Daisy documentation.

I never realised that people pay more attention to urls than to the 
menu. Sorry for that and sorry for not communicating all these ideas and 
decisions.

Bye, Helma


Re: [DOCS] Building for release - update

Posted by Vadim Gritsenko <va...@reverycodes.com>.
hepabolu wrote:
> The top-level can probably used as is with the exception of the live 
> sites, these are updated in Daisy.

We could migrate top level into Daisy as well, but only when we iron out issues 
with 2.1 docs...

I'd suggest as well to move "live sites" docs out of 2.1 daisy docs, and keep 
current top level live docs, till we move top level docs to daisy.

Vadim

Re: [DOCS] Building for release - update

Posted by Ross Gardler <rg...@apache.org>.
hepabolu wrote:
> hepabolu wrote:
> 
>> In short: after I've added the missing nodeIds and Ross changed the 
>> site.xml file in Forrest, the only thing left are the links from the 
>> samples into the docs.
>> The top-level can probably used as is with the exception of the live 
>> sites, these are updated in Daisy.
> 
> 
> AFAICT I fixed all missing nodeIds.

Great stuff Helma.

This approach enabled me to easily modify the Forrest plugin to handle 
the imports, so we are still mirroring the nav documents in Daisy 
without any changes in Forrest to the site structure.

Currently, what happens is that if a Daisy navigation node contains an 
import then it doesn't add anything to the URL-Space for that node. When 
I have more time I'll make this more configurable, but hopefully it will 
be sufficient for this.

WARNING
-------

I have *NOT* tested this very extensively, in fact I've just done a few 
simple manual checks, I've not even done a full site build. I have a 
very early start tomorrow and I'm going to bed now.

The next build of the ForrestBot will reveal all, if we get no message 
to this list then the build went well, so it is time to see how close to 
the required URL Space we are.

The next build is due in 1.5 hours (that is 2 am UTC).

I'm not able to look into this again until Friday AM (UTC + 1).

Ross

Re: [DOCS] Building for release - update

Posted by hepabolu <he...@gmail.com>.
hepabolu wrote:

> In short: after I've added the missing nodeIds and Ross changed the 
> site.xml file in Forrest, the only thing left are the links from the 
> samples into the docs.
> The top-level can probably used as is with the exception of the live 
> sites, these are updated in Daisy.

AFAICT I fixed all missing nodeIds.

Bye, Helma

Re: [DOCS] Building for release - update

Posted by hepabolu <he...@gmail.com>.
Ross Gardler wrote:
> <about label="About">
>   <xi:include href="cocoon://daisy.site.ABOUT_NAV_SECTION"/>
> </about>
> <documentation label="Documentation">
>   <xi:include href="cocoon://daisy.site.DOCUMENTATION_NAV_SECTION"/>
> </documentation>
> etc.

Right, I've updated the navigation document of the Daisy legacydocs. It 
now consists of group items (About, Documentation, Status ...) each 
containing an import of a navigation document that is named

groupname_NAV_SECTION (ABOUT_NAV_SECTION, etc).

I've created a new live site document that includes the other documents 
to recreate one page containing all versions, to mimic the current page 
on the cocoon.apache.org site.

There are some issues left:

- the planning part under "status" is slightly different, due to the 
same problem that happened in the top level. However, since most of 
these pages are outdated and because it concerns only about 5 pages, I 
don't see much point in restructuring this part as well.

- when moving over the content of the xdocs section I focused on the 
menu and making sure that the content was either in Daisy or, when I 
couldn't find the corresponding page in xdocs, I made sure there was a 
link to the corresponding page in the cocoon.apache.org site. There is a 
lot of jumping around between top-level and 2.1 that just created the 
confusion. This means that some parts of the top-level ended up in 
Daisy, some didn't.
I still don't see the value of the top-level part of Cocoon not being 
part of the 2.1 version. But let's postpone that discussion until after 
the 2.1.8 release.

- when updating the documentation I changed a few pages, in the portal 
and authentication part. I merely split the pages into chunks of more 
manageable size. I'll try to give these parts a meaningful URL (rather 
than a number), but that's only for hiding the number, I'm more and more 
inclined to a complete overhaul of the docs after 2.1.8 release and get 
rid of legacy urls.

- I didn't realise there were samples pointing to the docs. I've seen 
the Lucene sample issue discussed. I can't think of a quick/temporary fix.

- I noticed some of the cforms pages have no nodeIds added, I'll try to 
add those tomorrow.

In short: after I've added the missing nodeIds and Ross changed the 
site.xml file in Forrest, the only thing left are the links from the 
samples into the docs.
The top-level can probably used as is with the exception of the live 
sites, these are updated in Daisy.

Bye, Helma

Re: [DOCS] Building for release - update

Posted by Ross Gardler <rg...@apache.org>.
hepabolu wrote:
> Ross Gardler wrote:
> 
>>
>> <about label="About">
>>   <xi:include href="cocoon://daisy.site.ABOUT_NAV_SECTION"/>
>> </about>
>> <documentation label="Documentation">
>>   <xi:include href="cocoon://daisy.site.DOCUMENTATION_NAV_SECTION"/>
>> </documentation>
>> etc.
>>
> 
> Sounds ok and I'll give it a try on the Daisy side, but do be aware that 
> solving the top level is not 100% solution, I do remember that I've 
> changed similar things at a deeper nested level, just can't remember where.

We'll have to do it at each nested level then - not ideal, but Bruno has 
confirmed, via the Daisy list, that it is not possible to create a 
navigational group of documents that does not correspond to something in 
the URL Space.

Lets see how disjointed the nav documents would become, it seems to make 
sense to split out the major sections, such as user docs, develop docs 
etc. It might even make sense to split out, for example, the forms docs 
and portal docs, but it would not be good to be forced into splitting 
much further than that (e.g. sub sections within forms).

If this turns out to be too fiddly we could add some .htaccess rules to 
handle the deeply nested items. The issue (I believe), is to ensure that 
  existing links to the docs are not broken, it is not that we have to 
have the same URL space.

Ross
Ross

Re: [DOCS] Building for release - update

Posted by hepabolu <he...@gmail.com>.
Ross Gardler wrote:
> 
> <about label="About">
>   <xi:include href="cocoon://daisy.site.ABOUT_NAV_SECTION"/>
> </about>
> <documentation label="Documentation">
>   <xi:include href="cocoon://daisy.site.DOCUMENTATION_NAV_SECTION"/>
> </documentation>
> etc.
> 

Sounds ok and I'll give it a try on the Daisy side, but do be aware that 
solving the top level is not 100% solution, I do remember that I've 
changed similar things at a deeper nested level, just can't remember where.

> If someone else can handle the Daisy end of things I can handle to 

I'll do this in Daisy. Let's see where that takes us.

> Forrest end, but probably not until Friday as most of tomorrow (GMT) is 
> a travelling day. If anyone wants to handle the Forrest end beofore 
> then, the above examples should be enough, if not David and/or the 
> Forrest user list will help out I am sure.

Bye, Helma

Re: [DOCS] Building for release - update round 2

Posted by hepabolu <he...@gmail.com>.
Ross Gardler wrote:
> Butchering the Daisy nav docs will work, is quick and easy and can be 
> reverted in 2.2 release.

Since it's the legacy docs, I don't mind. The 2.2. docs will use the 
other site and the other documentation collection.

I don't mind doing it, since it's basically copy and paste, but I'd like 
to know which sections should be done apart from userforms/forms/

Bye, Helma


Re: [DOCS] Building for release - update round 2

Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:

...

> 
>>> * Extra URI segments:
>>
>>Some of these are a result of the lack of a clean build space (i.e. 
>>about/), but others are the same problem with the daisy navigation, for 
>>example, the extra dirs under /userdocs/forms/
>>
>>Helma did warns us that there were other places the URLspace had been 
>>changed in Daisy, I was hoping it would be less widespread than this 
>>though :-(
>>
>>I'm looking into it.
> 
> 
> What is the status of this? Did you produce a new list
> for Vadim, or someone else, to verify?

I've been inundated with work lately and have been unable to do anything 
about this.

It can be solved by the same method as the previous extra info in the 
URL space, however, in some places this will result in navigation docs 
that are too fragmented on Daisy.

The other options are for us to put in the code to support extra nodes 
in the Daisy to allow "Title" nodes that do not have a corresponding URL 
entry. Bruno suggested this on the Daisy list so he is receptive to the 
idea, problem is finding the time to do it, I have no idea how easy/hard 
it is (Bruno said it would be fairly easy, but then Bruno knows Daisy 
code inside out ;-)

.htaccess is a quick and dirty solution to get the release out.

Butchering the Daisy nav docs will work, is quick and easy and can be 
reverted in 2.2 release.

I'm afraid I am unlikely to get any real time on this until much later 
this week (possibly as late as Friday). So it's up to you folk.

Ross

Ross


Re: [DOCS] Building for release - update round 2

Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Vadim Gritsenko wrote:
> >Ross Gardler wrote:
> >
> >>I just sent it offlist, but I sent it from the zone, not sure if mail 
> >>is set up correctly there. If you don't recieive it you can get it at 
> >>http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/fileList.txt
> >
> >Got the mail ok.
> >
> >>(note this is not regenerated when the site is rebuilt)
> 
> >Diff attached. Lots of differences, I'll sum up some of them here:
> 
> Thanks for this Vadim, saves us lots of time - sorry it wasn't as 
> encouraging as I thought.
> 
> >  * Duplicates: See example above. Was it simply because output
> >    directory was not cleared up between forrest runs?
> 
> Yes, that is the problem, as David identified. I'm discussing with David 
> as to whether the Forrestbot should always clear out its build directory 
> on a new run (I thought it did).

I manually did that cleanout for now.

> >  * Extra URI segments:
> 
> Some of these are a result of the lack of a clean build space (i.e. 
> about/), but others are the same problem with the daisy navigation, for 
> example, the extra dirs under /userdocs/forms/
> 
> Helma did warns us that there were other places the URLspace had been 
> changed in Daisy, I was hoping it would be less widespread than this 
> though :-(
> 
> I'm looking into it.

What is the status of this? Did you produce a new list
for Vadim, or someone else, to verify?

-David

Re: [DOCS] Building for release - update round 2

Posted by David Crossley <cr...@apache.org>.
Vadim Gritsenko wrote:
> 
> Hm, why some files are there twice? Example:
> 
>   /developing/concepts/avalon.html
>   /documentation/developing/concepts/avalon.html

I know why. It is because the forrestbot didn't clean
out its workspace on the server. So the old generated
documents are still included. I will go do that
Next run will be the actual set.

-David

Re: TOCs in documentation (Re: [DOCS] Building for release - update round 2)

Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
> 
>>Vadim Gritsenko wrote:
>>
>>>Ross Gardler wrote:
>>>
>>>>Vadim Gritsenko wrote:
>>>>
>>>>
>>>>>Forgot to add... Can we loose page toc which now appears within left 
>>>>>navigation bar? I'm not sure we should have it there, it certainly 
>>>>>looks strange...
>>>>
>>>>It was moved there as a test, come people like it in the body, come in 
>>>>the page menu, some not at all.
>>>>
>>>>It is easy to move/remove (a setting in skinconf.xml in the 
>>>>daisy-to-docs module) - the question is where do we want it (or do we 
>>>>want to remove it).
>>>
>>>I am in "remove it completely" camp...
>>
>>On the Cocoon site, I am too, lets leave it for a while with the new 
>>subject line and see if anyone objects to us removing it completely.
> 
> 
> As i said earlier in this thread, i prefer the ToC in the
> top of the page body (probably listing only one level).
> I definitely do not like it in the side-panel menu.
> But really i don't care if others want it gone completely.

I'' remove it completely. Some others have stated that they don't like 
it in the top.

Ross

Re: TOCs in documentation (Re: [DOCS] Building for release - update round 2)

Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Vadim Gritsenko wrote:
> >Ross Gardler wrote:
> >>Vadim Gritsenko wrote:
> >>
> >>>Forgot to add... Can we loose page toc which now appears within left 
> >>>navigation bar? I'm not sure we should have it there, it certainly 
> >>>looks strange...
> >>
> >>It was moved there as a test, come people like it in the body, come in 
> >>the page menu, some not at all.
> >>
> >>It is easy to move/remove (a setting in skinconf.xml in the 
> >>daisy-to-docs module) - the question is where do we want it (or do we 
> >>want to remove it).
> >
> >I am in "remove it completely" camp...
> 
> On the Cocoon site, I am too, lets leave it for a while with the new 
> subject line and see if anyone objects to us removing it completely.

As i said earlier in this thread, i prefer the ToC in the
top of the page body (probably listing only one level).
I definitely do not like it in the side-panel menu.
But really i don't care if others want it gone completely.

-David

Re: [DOCS] Building for release - update round 2

Posted by David Crossley <cr...@apache.org>.
Vadim Gritsenko wrote:
> Ross Gardler wrote:
> >Vadim Gritsenko wrote:
> >
> >>Forgot to add... Can we loose page toc which now appears within left 
> >>navigation bar? I'm not sure we should have it there, it certainly 
> >>looks strange...
> >
> >It was moved there as a test, come people like it in the body, come in 
> >the page menu, some not at all.
> >
> >It is easy to move/remove (a setting in skinconf.xml in the 
> >daisy-to-docs module) - the question is where do we want it (or do we 
> >want to remove it).
> 
> I am in "remove it completely" camp...

I definitely don't like the ToC embedded in the
left-hand menu.

The top-of-page ToC is good though, e.g. see
http://cocoon.apache.org/2.1/performancetips.html

Though one day it would be good to utilise that
whitespace.

The ToC needs to be configured to less levels
perhaps just one or maybe two levels. Otherwise
some pages get confusing.

-David

Re: [DOCS] Building for release - update round 2

Posted by David Crossley <cr...@apache.org>.
Vadim Gritsenko wrote:
> hepabolu wrote:
> 
> > > -/changes.html
> >
> >This is so outdated (see http://cocoon.apache.org/changes.html) that I 
> >would be ashamed to put it up again. So it's missing from Daisy (also 
> >because it's toplevel) and therefore from forrest.zones.

Not correct, please read the other recent threads about this.

> This is generated from status.xml 
> (http://cocoon.apache.org/2.1/changes.html), same as todo.html.

The reason that that page appears to be "outdated"
is that no committers have found the wherewithall
to update the website since the last release.
These pages are generated, so if no-one does it
then it doesn't happen.

As i said in another thread there are hundreds of
new entries recorded in the status.xml file.

As i said in another thread i am still trying to
find new ways to generate that since the old
Cocoon-2.1 docs build is now broken.

-David

TOCs in documentation (Re: [DOCS] Building for release - update round 2)

Posted by Ross Gardler <rg...@apache.org>.
Vadim Gritsenko wrote:
> Ross Gardler wrote:
> 
>> Vadim Gritsenko wrote:
>>
>>> Forgot to add... Can we loose page toc which now appears within left 
>>> navigation bar? I'm not sure we should have it there, it certainly 
>>> looks strange...
>>
>>
>> It was moved there as a test, come people like it in the body, come in 
>> the page menu, some not at all.
>>
>> It is easy to move/remove (a setting in skinconf.xml in the 
>> daisy-to-docs module) - the question is where do we want it (or do we 
>> want to remove it).
> 
> 
> I am in "remove it completely" camp...

On the Cocoon site, I am too, lets leave it for a while with the new 
subject line and see if anyone objects to us removing it completely.

Ross

Re: [DOCS] Building for release - update round 2

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ross Gardler wrote:
> Vadim Gritsenko wrote:
> 
>> Forgot to add... Can we loose page toc which now appears within left 
>> navigation bar? I'm not sure we should have it there, it certainly 
>> looks strange...
> 
> It was moved there as a test, come people like it in the body, come in 
> the page menu, some not at all.
> 
> It is easy to move/remove (a setting in skinconf.xml in the 
> daisy-to-docs module) - the question is where do we want it (or do we 
> want to remove it).

I am in "remove it completely" camp...

Vadim

Re: [DOCS] Building for release - update round 2

Posted by Ross Gardler <rg...@apache.org>.
Vadim Gritsenko wrote:
> Vadim Gritsenko wrote:
> 
>> Ross Gardler wrote:
>>
>>> Perhaps Vadim can create a diff for us again to check this status, 
>>> once the build has completed in around 3 hours.
>>
>>
>> Cool stuff.
> 
> 
> Forgot to add... Can we loose page toc which now appears within left 
> navigation bar? I'm not sure we should have it there, it certainly looks 
> strange...

It was moved there as a test, come people like it in the body, come in 
the page menu, some not at all.

It is easy to move/remove (a setting in skinconf.xml in the 
daisy-to-docs module) - the question is where do we want it (or do we 
want to remove it).

Ross

Re: [DOCS] Building for release - update round 2

Posted by hepabolu <he...@gmail.com>.
Vadim Gritsenko wrote:
> Vadim Gritsenko wrote:
> 
>> Ross Gardler wrote:
>>
>>> Perhaps Vadim can create a diff for us again to check this status, 
>>> once the build has completed in around 3 hours.
>>
>>
>> Cool stuff.
> 
> 
> Forgot to add... Can we loose page toc which now appears within left 
> navigation bar? I'm not sure we should have it there, it certainly looks 
> strange...
> 
> Vadim
> 

:-) it was moved there because it looks odd/old fashioned at the top of 
the page.
Personally I don't mind if it's removed all together.

Bye, Helma


Re: [DOCS] Building for release - update round 2

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Vadim Gritsenko wrote:
> Ross Gardler wrote:
> 
>> Perhaps Vadim can create a diff for us again to check this status, 
>> once the build has completed in around 3 hours.
> 
> Cool stuff.

Forgot to add... Can we loose page toc which now appears within left navigation 
bar? I'm not sure we should have it there, it certainly looks strange...

Vadim

Re: [DOCS] Building for release - update round 2

Posted by Ross Gardler <rg...@apache.org>.
Vadim Gritsenko wrote:
> Ross Gardler wrote:
> 
>> I just sent it offlist, but I sent it from the zone, not sure if mail 
>> is set up correctly there. If you don't recieive it you can get it at 
>> http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/fileList.txt
> 
> 
> Got the mail ok.
> 
> 
>> (note this is not regenerated when the site is rebuilt)
>>

..

> Diff attached. Lots of differences, I'll sum up some of them here:

Thanks for this Vadim, saves us lots of time - sorry it wasn't as 
encouraging as I thought.

> 
>   * Duplicates: See example above. Was it simply because output
>     directory was not cleared up between forrest runs?

Yes, that is the problem, as David identified. I'm discussing with David 
as to whether the Forrestbot should always clear out its build directory 
on a new run (I thought it did).

>   * Extra URI segments:

Some of these are a result of the lack of a clean build space (i.e. 
about/), but others are the same problem with the daisy navigation, for 
example, the extra dirs under /userdocs/forms/

Helma did warns us that there were other places the URLspace had been 
changed in Daisy, I was hoping it would be less widespread than this 
though :-(

I'm looking into it.

Ross

Re: [DOCS] Building for release - update round 2

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ross Gardler wrote:
> I just sent it offlist, but I sent it from the zone, not sure if mail is 
> set up correctly there. If you don't recieive it you can get it at 
> http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/fileList.txt

Got the mail ok.


> (note this is not regenerated when the site is rebuilt)
> 
> The two files forms/binding/binding.html and 
> forms/binding/xmlbinding.html will become the correct files. The only 
> other known problem at this stage is i18n-transformer is now 
> i18nTransformer (see earlier mail)

Hm, why some files are there twice? Example:

   /developing/concepts/avalon.html
   /documentation/developing/concepts/avalon.html


Diff attached. Lots of differences, I'll sum up some of them here:

   * Duplicates: See example above. Was it simply because output
     directory was not cleared up between forrest runs?

   * Extra URI segments:

       /about
       /concepts       (under /developing)
       /gettingstarted (under /faq)
       /sitemap        (under /faq)
       /using          (under /faq)
       /cocoon         (under /howto)
       /contribution   (under /howto)
       /documentation  (under /howto)
       /testing        (under /installing)
       /documentation  (under /plan)
       /otherplanning  (under /plan)
       /overview       (under /plan)
       /api            (under /userdocs/forms)
       /basics         (under /userdocs/forms)
       /binding        (under /userdocs/forms)
       /publishing     (under /userdocs/forms)
       /widgetconcepts (under /userdocs/forms)
       /widgets        (under /userdocs/forms)
       /sitemap-components (under /userdocs)
       /core           (under /userdocs/sitemap-components/generators)
       /optional       (under /userdocs/sitemap-components/generators)
       /core           (under /userdocs/sitemap-components/matchers)
       /optional       (under /userdocs/sitemap-components/matchers)
       /core           (under /userdocs/sitemap-components/readers)
       /optional       (under /userdocs/sitemap-components/readers)
       /scratchpad     (under /userdocs/sitemap-components/readers)
       /core           (under /userdocs/sitemap-components/selectors)
       /scratchpad     (under /userdocs/sitemap-components/selectors)
       /core           (under /userdocs/sitemap-components/serializers)
       /optional       (under /userdocs/sitemap-components/serializers)
       /core           (under /userdocs/sitemap-components/transformers)
       /optional       (under /userdocs/sitemap-components/transformers)
       /logicsheets    (under /userdocs/xsp)

   * Different URI segments:

       /snippets vs. /snippet


Vadim

Re: [DOCS] Building for release - update round 2

Posted by Ross Gardler <rg...@apache.org>.
Vadim Gritsenko wrote:
> Ross Gardler wrote:
> 
>> Perhaps Vadim can create a diff for us again to check this status, 
>> once the build has completed in around 3 hours.
> 
> 
> Cool stuff.
> 
> Send me result of
>   find . -name "*.html"

I just sent it offlist, but I sent it from the zone, not sure if mail is 
set up correctly there. If you don't recieive it you can get it at 
http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/fileList.txt

(note this is not regenerated when the site is rebuilt)

The two files forms/binding/binding.html and 
forms/binding/xmlbinding.html will become the correct files. The only 
other known problem at this stage is i18n-transformer is now 
i18nTransformer (see earlier mail)

Ross

Re: [DOCS] Building for release - update round 2

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ross Gardler wrote:
> Perhaps Vadim can create a diff for us again 
> to check this status, once the build has completed in around 3 hours.

Cool stuff.

Send me result of
   find . -name "*.html"

from http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/ and I'll compare 
with old url space (i don't have access to forrest.zones).

Vadim

Re: [DOCS] Building for release - update round 2

Posted by Ross Gardler <rg...@apache.org>.
hepabolu wrote:
> Ross Gardler wrote:
> 
>> Two of the others had the same problem: 2.1/forms/binding.html and 
>> 2.1/forms/xmlbinding.html.
> 
> 
> Since this concerns only 2 files, just remove the grouping in Daisy so 
> the url space matches. They both have "binding" in their label, so it 
> should stand out in the menu. That solves the url change as well as the 
> link problem.

That makes sense, I did that, next build will show the change.

>> The last one 
>> 2.1/userdocs/sitemap-components/transformers/core/i18n-transformer.html 
>> is a problem with Forrest. It uses a pattern of "**i18n-*.html" 
>> internally for some of its internationalisation stuff. This is 
>> obviously not good, I've raised an issue in Forrest, but it is too big 
>> a job fix now.
>>
>> I've therefore renamed this file to i18nTransformer as a workaround. 
>> But  of course, this creates another change URL.
> 
> 
> so an .htaccess then?

Yes, I think so.

Ross

Re: [DOCS] Building for release - update round 2

Posted by hepabolu <he...@gmail.com>.
Ross Gardler wrote:

> The first (2.1/index.html) didn't appear anywhere in the Daisy nav menu 
> so Forrest had no way of knowing how to find it. I just added index to 
> the About section.

Fine.

> Two of the others had the same problem: 2.1/forms/binding.html and 
> 2.1/forms/xmlbinding.html.

Since this concerns only 2 files, just remove the grouping in Daisy so 
the url space matches. They both have "binding" in their label, so it 
should stand out in the menu. That solves the url change as well as the 
link problem.

> The last one 
> 2.1/userdocs/sitemap-components/transformers/core/i18n-transformer.html 
> is a problem with Forrest. It uses a pattern of "**i18n-*.html" 
> internally for some of its internationalisation stuff. This is obviously 
> not good, I've raised an issue in Forrest, but it is too big a job fix now.
> 
> I've therefore renamed this file to i18nTransformer as a workaround. But 
>  of course, this creates another change URL.

so an .htaccess then?

Bye, Helma

Re: [DOCS] Building for release - update round 2

Posted by Ross Gardler <rg...@apache.org>.
hepabolu wrote:
> Ross Gardler wrote:
> 
>>> Note, somehow only the menu is up on forrest.zones, all linked pages 
>>> are gone. I suspect this is due to the split in the navigation doc in 
>>> Daisy and should be fixed when Ross adjusts the appropriate files in 
>>> Forrest.
>>
>>
>> I'm not seeing this. I see the full contents of the site, all looking 
>> lovely, with the corect URLspace. Are you still seeing this problem?
> 
> 
> Just checked: no everything seems fine.
> 
> 
>> There are three broken links in the site build now, I'll look at those 
>> tomorrow morning (UTC), if someone else wants to have a go at it the 
>> broken links are shown on:
>>
>> http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml
> 
> 
> IIUC there are four broken links, but I have no clue how to fix it, sorry.

Yes, there were four.

The first (2.1/index.html) didn't appear anywhere in the Daisy nav menu 
so Forrest had no way of knowing how to find it. I just added index to 
the About section.

(NOTE there was a link to the index page used on daisy, but that is not 
the index page for the site so I removed that, you still see the daisy 
index when you go to the legacy docs on daisy itself).

Two of the others had the same problem: 2.1/forms/binding.html and 
2.1/forms/xmlbinding.html.

The problem here is the fact that daisy does not allow grouping of 
documents without adding something to the path. There are only two files 
in this section of the navigation, so I don't think it is worth creating 
a separate nav document for them like we did with the higher level 
nodes, although that would solve the problem.

I propose we either accept these as changed URLs and we add .htaccess 
rules for these two files. They are now at 
2.1/forms/binding/binding.html and 2.1/forms/binding/xmlbinding.html

If that is not acceptagble then someone needs to do as Helma did and 
create an import node for these two docs.

The last one 
2.1/userdocs/sitemap-components/transformers/core/i18n-transformer.html 
is a problem with Forrest. It uses a pattern of "**i18n-*.html" 
internally for some of its internationalisation stuff. This is obviously 
not good, I've raised an issue in Forrest, but it is too big a job fix now.

I've therefore renamed this file to i18nTransformer as a workaround. But 
  of course, this creates another change URL.

I just did a test build and there are now no broken links. So, if our 
work has worked (next forrestbot build will confirm/deny this) we should 
be down to just three (or even one) changed URLs, quite manageable with 
an .htaccess file I think. Perhaps Vadim can create a diff for us again 
to check this status, once the build has completed in around 3 hours.

For the future:

Bruno has suggested a change (on the Daisy list) to Daisy that will 
allow us to Group items without affecting the urlspace. So we can fix 
this problem in future releases (there is another Daisy user needs this 
too, so hopefully one of us will implement it). We'll also fix the 
"i18n-" urlspace limitation in Forrest.

Ross



Re: [DOCS] Building for release - update round 2

Posted by hepabolu <he...@gmail.com>.
Ross Gardler wrote:
>> Note, somehow only the menu is up on forrest.zones, all linked pages 
>> are gone. I suspect this is due to the split in the navigation doc in 
>> Daisy and should be fixed when Ross adjusts the appropriate files in 
>> Forrest.
> 
> I'm not seeing this. I see the full contents of the site, all looking 
> lovely, with the corect URLspace. Are you still seeing this problem?

Just checked: no everything seems fine.


> There are three broken links in the site build now, I'll look at those 
> tomorrow morning (UTC), if someone else wants to have a go at it the 
> broken links are shown on:
> 
> http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml

IIUC there are four broken links, but I have no clue how to fix it, sorry.

Bye, Helma


Re: [DOCS] Building for release - update round 2

Posted by Ross Gardler <rg...@apache.org>.
hepabolu wrote:
> Vadim Gritsenko wrote:
> 
>> Results are encouraging - now diff between old URI space and new 
>> version is much smaller (attached as well)
>>
>> Note that there are several numbered docs in there - either 
>> mislabelled old docs or newly added docs, i have not checked.
> 
> 
> Note, somehow only the menu is up on forrest.zones, all linked pages are 
> gone. I suspect this is due to the split in the navigation doc in Daisy 
> and should be fixed when Ross adjusts the appropriate files in Forrest.

I'm not seeing this. I see the full contents of the site, all looking 
lovely, with the corect URLspace. Are you still seeing this problem?

There are three broken links in the site build now, I'll look at those 
tomorrow morning (UTC), if someone else wants to have a go at it the 
broken links are shown on:

http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml

They look like they are in the index file since they are referenced from 
a great many pages.

> Here are snippets of your diff that I want to comment on:

I'll look at this later in the thread, after I have read Vadims response.

Ross

Re: [DOCS] Building for release - update round 2

Posted by hepabolu <he...@gmail.com>.
David Crossley wrote:

> This highlights a huge misunderstanding. The docs must
> be generated and updated on the website as often as
> possible, not just at release time.

True, but I was talking about the specific jars.html page for the 
upcoming release. Since we've decided that the 2.1 branch is going to be 
replaced by 2.2, I suppose there will hardly be any updates to the 2.1 
docs, nor the jars.html page for the 2.1 branch.

For the 2.2 release we can do it differently.

Yes, I'm all for frequent updates of the docs website. The old way had 
some serious road blocks resulting in hardly any doc updates and very 
few website updates.
The current way (editing in Daisy) removed the doc editing road block. 
We just have to figure out how we can make the conversion process from 
Daisy to website.
If there was any misunderstanding it was my perception that Daisy could 
be used for both editing and official website.

Bye, Helma

Re: [DOCS] Building for release - update round 2

Posted by David Crossley <cr...@apache.org>.
hepabolu wrote:
> David Crossley wrote:
> 
> >Another issue is that the useful table of libraries used with
> >Cocoon was generated by the Cocoon "docs" target by analysing
> >gump.xml IIRC.
> >http://cocoon.apache.org/2.1/installing/jars.html
> >http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/installing/jars.html
> 
> Hmm, could you generate this with the same workaround as the 
> changes.html page?

No it cannot. As i said, it was an intergral part of
the Cocoon "build.sh|build.bat" process. Then forrest
just rendered it. The data needs to be prepared.

> I guess this is a one time process, since it's Cocoon 2.1.8. So no use 
> to spend much time to setting up a nifty process if it's only used once 
> or twice.

This highlights a huge misunderstanding. The docs must
be generated and updated on the website as often as
possible, not just at release time.

-David

> For Cocoon 2.2 we should find a different process.
> 
> WDYT?
> 
> Bye, Helma

Re: [DOCS] Building for release - update round 2

Posted by hepabolu <he...@gmail.com>.
David Crossley wrote:

> generation. So someone will need to search Daisy and
> replace those tags.

Just checked: there were 3, one of them retired. I changed it to (2.1.8) 
or (currently 2.1.8) whatever was more appropriate.

The retired one, I didn't change.

Bye, Helma

Re: [DOCS] Building for release - update round 2

Posted by hepabolu <he...@gmail.com>.
Ross Gardler wrote:
> hepabolu wrote:
> 
>> David Crossley wrote:
>>
>>> There are a number of places in the source documents with the
>>> token "@released.version@", e.g.
>>> http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/index.html
>>
>>
>>
>> I'll see to this.
> 
> 
> I don't know how big a job this is. But if it is still worthwhile the 
> Daisy plugin allows for Daisy documents to be pre and post filtered 
> through and XSL. We can therefore automatically replace these tokens if 
> you want to.

Done already, it was only 2 docs.

Bye, Helma


Re: [DOCS] Building for release - update round 2

Posted by Ross Gardler <rg...@apache.org>.
hepabolu wrote:
> David Crossley wrote:
> 
>> There are a number of places in the source documents with the
>> token "@released.version@", e.g.
>> http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/index.html
> 
> 
> I'll see to this.

I don't know how big a job this is. But if it is still worthwhile the 
Daisy plugin allows for Daisy documents to be pre and post filtered 
through and XSL. We can therefore automatically replace these tokens if 
you want to.

Ross

Re: [DOCS] Building for release - update round 2

Posted by hepabolu <he...@gmail.com>.
David Crossley wrote:
> There are a number of places in the source documents with the
> token "@released.version@", e.g.
> http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/index.html

I'll see to this.

> Another issue is that the useful table of libraries used with
> Cocoon was generated by the Cocoon "docs" target by analysing
> gump.xml IIRC.
> http://cocoon.apache.org/2.1/installing/jars.html
> http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/installing/jars.html


Hmm, could you generate this with the same workaround as the 
changes.html page?
I guess this is a one time process, since it's Cocoon 2.1.8. So no use 
to spend much time to setting up a nifty process if it's only used once 
or twice.

For Cocoon 2.2 we should find a different process.

WDYT?

Bye, Helma


Re: [DOCS] Building for release - update round 2

Posted by David Crossley <cr...@apache.org>.
There are a number of places in the source documents with the
token "@released.version@", e.g.
http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/index.html

These are remnants of the previous build system, where the
Cocoon build target "docs" used to copy the sources and
replace those tokens, then forrest took over to do the
generation. So someone will need to search Daisy and
replace those tags.

Another issue is that the useful table of libraries used with
Cocoon was generated by the Cocoon "docs" target by analysing
gump.xml IIRC.
http://cocoon.apache.org/2.1/installing/jars.html
http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/installing/jars.html

-David

Re: [DOCS] Building for release - update round 2

Posted by Vadim Gritsenko <va...@reverycodes.com>.
hepabolu wrote:
> Here are snippets of your diff that I want to comment on:
> 
>  > +/692.html
>  > +/692.html
>  > +/692.html
> 
> I'm not sure where you found this one,

Me too. Had this in locationmap

   <match pattern="2.1/692.daisy.source"><location 
src="http://publish:publish@cocoon.zones.apache.org:9263/publisher/document?documentId=692&amp;includeNavigation=false&amp;locale=en_US&amp;version=live"/></match>


> because it doesn't show up on the 
> forrest.zone set. In Daisy I used it to work around a little problem in 
> the navigation doc: if a group contains only links to external pages, it 
> doesn't open because there is no internal document to display. The 
> content of this page is reflected in the forrest.zones set similar to 
> the cocoon.apache.org set, with one exception:
> 
> the "Links" section is not present in forrest.zones although it is 
> present in Daisy.
> 
> 
>  > -/catalog-test.html
> 
> IIUC this is only present in the repository, but not on 
> cocoon.apache.org and also not in Daisy. It is beyond me to grasp the 
> value of this page, so AFAIC I won't put any effort into it to get it on 
> the website. Again, this is toplevel, so that explains its absence as well.

No this is not top level, everything in this diff is under /2.1/. I removed this 
document as its value was only for testing running Cocoon instance, and it is 
not needed to be on docs site.


>  > -/changes.html
> 
> This is so outdated (see http://cocoon.apache.org/changes.html) that I 
> would be ashamed to put it up again. So it's missing from Daisy (also 
> because it's toplevel) and therefore from forrest.zones.

This is generated from status.xml (http://cocoon.apache.org/2.1/changes.html), 
same as todo.html.


>  > +/developing/portal/authentication.html
> 
> In the original site, this points to 
> /developing/webapps/authentication.html. Although Daisy also refers to 
> the same document, it is now available under two urls. No showstopper 
> for me.
> 
>  > /developing/portal/coplets.html
>  > +/developing/portal/coplets/cachinguricoplet.html
>  > +/developing/portal/coplets/uricoplet.html
> 
> The two pages below are extracted from the huge coplets.html file and 
> put in separate pages to keep the info more readable. They can be 
> reached through the menu see forrest.zones.
> 
> There was an issue with an extra /portal/ in the url. I've fixed that. 
> Only thing that remains are the samples:
> daisy export: /developing/portal/samples/forms.html + .../basket.html
> cocoon.apache.org: /developing/portal/forms.html + .../basket.html
> 
> 
>  > +/developing/portal/layout_skins.html
>  > +/developing/portal/wsrp.html
> 
> New content
> 
>  > +/developing/webapps/604.html
> 
> Fixed
> 
> 
>  > +/developing/webapps/application_management.html
>  > +/developing/webapps/authenticating_user.html
>  > +/developing/webapps/module_management.html
>  > +/developing/webapps/pipeline_patterns.html
>  > +/developing/webapps/summary.html
>  > +/developing/webapps/user_administration.html
>  > +/developing/webapps/user_management.html
> 
> Same as for the portal: this was all part of one huge 
> "authentication.html" file. I've split it into different smaller files 
> to keep it more readable. They are all in the menu.
> 
>  > -/installing/requirements.html
> 
> Fixed
> 
>  > -/plan/changes-doc.html
>  > -/plan/issues-doc.html
>  > -/plan/review-sitemap-docs.html
>  > -/plan/todo-doc.html
> 
> These are very old and very outdated. The info is either done or not 
> valid any more. When we want to have a "hip and modern" Cocoon, these 
> pages provide the opposite signal. Since they deal with documentation 
> only, I suggest to simply leave them out. If people think the 
> information is worthwhile keeping, I suggest we either move them to 
> Daisy but only for archiving purposes, or we move the info to the wiki.

I'd prefer to remove them too.


>  > -/todo.html
> 
> IIUC this is genererated from status.xml, so I didn't do anything with 
> this, although I think this is a good candidate for either Jira (most 
> obvious place) or a Daisy document (easier to get an overview).
> 
> 
>  > +/userdocs/forms/ajax.html
>  > +/userdocs/forms/formlibraries.html
>  > +/userdocs/forms/improving_sample.html
>  > +/userdocs/forms/selectionlists.html
>  > +/userdocs/forms/templating.html
>  > +/userdocs/forms/widget_class.html
>  > +/userdocs/forms/widget_form.html
>  > +/userdocs/forms/widget_group.html
>  > +/userdocs/forms/widget_imagemap.html
>  > +/userdocs/forms/widget_tree.html
>  > +/userdocs/forms/widget_union.html
>  > +/userdocs/forms/widgetstates.html
>  > +/userdocs/forms/xmlbinding.html
>  > +/userdocs/matchers/template-matcher.html
> 
> New content
> 
>  > -/userdocs/generators/sessionattribute-generator.html
>  > -/userdocs/transformers/jpath-transformer.html
>  > -/userdocs/transformers/role-filter-transformer.html
>  > -/userdocs/transformers/simple-form-instance-transformer.html
>  > -/userdocs/transformers/simple-form-transformer.html
> 
> I've recreated the pages, with hardly any info in it, for 
> url-compatibility sake. There were already links to the apidocs for 
> these classes.
> 
>  > +/userdocs/transformers/463.html
>  > -/userdocs/transformers/i18n-transformer.html
> 
> Fixed, 463 = i18n-transformer

Thanks

Vadim

Re: [DOCS] Building for release - update round 2

Posted by hepabolu <he...@gmail.com>.
Vadim Gritsenko wrote:

> Results are encouraging - now diff between old URI space and new version 
> is much smaller (attached as well)
> 
> Note that there are several numbered docs in there - either mislabelled 
> old docs or newly added docs, i have not checked.

Note, somehow only the menu is up on forrest.zones, all linked pages are 
gone. I suspect this is due to the split in the navigation doc in Daisy 
and should be fixed when Ross adjusts the appropriate files in Forrest.

Here are snippets of your diff that I want to comment on:

 > +/692.html
 > +/692.html
 > +/692.html

I'm not sure where you found this one, because it doesn't show up on the 
forrest.zone set. In Daisy I used it to work around a little problem in 
the navigation doc: if a group contains only links to external pages, it 
doesn't open because there is no internal document to display. The 
content of this page is reflected in the forrest.zones set similar to 
the cocoon.apache.org set, with one exception:

the "Links" section is not present in forrest.zones although it is 
present in Daisy.


 > -/catalog-test.html

IIUC this is only present in the repository, but not on 
cocoon.apache.org and also not in Daisy. It is beyond me to grasp the 
value of this page, so AFAIC I won't put any effort into it to get it on 
the website. Again, this is toplevel, so that explains its absence as well.

 > -/changes.html

This is so outdated (see http://cocoon.apache.org/changes.html) that I 
would be ashamed to put it up again. So it's missing from Daisy (also 
because it's toplevel) and therefore from forrest.zones.


 > +/developing/portal/authentication.html

In the original site, this points to 
/developing/webapps/authentication.html. Although Daisy also refers to 
the same document, it is now available under two urls. No showstopper 
for me.

 > /developing/portal/coplets.html
 > +/developing/portal/coplets/cachinguricoplet.html
 > +/developing/portal/coplets/uricoplet.html

The two pages below are extracted from the huge coplets.html file and 
put in separate pages to keep the info more readable. They can be 
reached through the menu see forrest.zones.

There was an issue with an extra /portal/ in the url. I've fixed that. 
Only thing that remains are the samples:
daisy export: /developing/portal/samples/forms.html + .../basket.html
cocoon.apache.org: /developing/portal/forms.html + .../basket.html


 > +/developing/portal/layout_skins.html
 > +/developing/portal/wsrp.html

New content

 > +/developing/webapps/604.html

Fixed


 > +/developing/webapps/application_management.html
 > +/developing/webapps/authenticating_user.html
 > +/developing/webapps/module_management.html
 > +/developing/webapps/pipeline_patterns.html
 > +/developing/webapps/summary.html
 > +/developing/webapps/user_administration.html
 > +/developing/webapps/user_management.html

Same as for the portal: this was all part of one huge 
"authentication.html" file. I've split it into different smaller files 
to keep it more readable. They are all in the menu.

 > -/installing/requirements.html

Fixed

 > -/plan/changes-doc.html
 > -/plan/issues-doc.html
 > -/plan/review-sitemap-docs.html
 > -/plan/todo-doc.html

These are very old and very outdated. The info is either done or not 
valid any more. When we want to have a "hip and modern" Cocoon, these 
pages provide the opposite signal. Since they deal with documentation 
only, I suggest to simply leave them out. If people think the 
information is worthwhile keeping, I suggest we either move them to 
Daisy but only for archiving purposes, or we move the info to the wiki.


 > -/todo.html

IIUC this is genererated from status.xml, so I didn't do anything with 
this, although I think this is a good candidate for either Jira (most 
obvious place) or a Daisy document (easier to get an overview).


 > +/userdocs/forms/ajax.html
 > +/userdocs/forms/formlibraries.html
 > +/userdocs/forms/improving_sample.html
 > +/userdocs/forms/selectionlists.html
 > +/userdocs/forms/templating.html
 > +/userdocs/forms/widget_class.html
 > +/userdocs/forms/widget_form.html
 > +/userdocs/forms/widget_group.html
 > +/userdocs/forms/widget_imagemap.html
 > +/userdocs/forms/widget_tree.html
 > +/userdocs/forms/widget_union.html
 > +/userdocs/forms/widgetstates.html
 > +/userdocs/forms/xmlbinding.html
 > +/userdocs/matchers/template-matcher.html

New content

 > -/userdocs/generators/sessionattribute-generator.html
 > -/userdocs/transformers/jpath-transformer.html
 > -/userdocs/transformers/role-filter-transformer.html
 > -/userdocs/transformers/simple-form-instance-transformer.html
 > -/userdocs/transformers/simple-form-transformer.html

I've recreated the pages, with hardly any info in it, for 
url-compatibility sake. There were already links to the apidocs for 
these classes.

 > +/userdocs/transformers/463.html
 > -/userdocs/transformers/i18n-transformer.html

Fixed, 463 = i18n-transformer

Bye, Helma

Re: [DOCS] Building for release - update

Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Vadim Gritsenko wrote:
> 
>> Ross Gardler wrote:
>>
>>> There are now three possible workarounds, it's up to others to pick 
>>> one and go with it in order to get the release out:

I managed to get enough time before my plane to look at the current 
problem with the new Daisy navigation + Forrest solution. I'm not sure 
why overnight builds didn't report problems, but there was an issue in 
the Forrest plugin. Now resolved, I think - again not tested, I'm about 
to leave the airport so can't do that.

If you want to use any of the other solutions that's fine by me, I'm 
just killing dead time.

Ross

Re: [DOCS] Building for release - update

Posted by Ross Gardler <rg...@apache.org>.
Vadim Gritsenko wrote:
> Ross Gardler wrote:
> 
>> There are now three possible workarounds, it's up to others to pick 
>> one and go with it in order to get the release out:
> 
> 
> Why can't we write locationmap.xml and supply it to Forrest instead of 
> torturing Daisy's navigation doc & Forrest Daisy plugin? Would it work?

The site.xml file is also being generated from the daisy navigation 
document. This is not a problem though, we should be able to use the 
"old" XDoc site.xml.

It should work though, although I can't guarentee it since the 
locationmap is also used to resolve internal links using the "daisy:" 
protocol. There will need to be a minor change to the 2.1/**.xml 
matchers in daisy-to-docs sitemap.xmap to handle this since we will no 
longer be using the daisy navigation document to define the URLspace.

> Attached is my take on locationmap.xml, mostly removing path fragments. 
> Results are encouraging - now diff between old URI space and new version 
> is much smaller (attached as well)

It's the internal links that will be a problem now :-(

> Note that there are several numbered docs in there - either mislabelled 
> old docs or newly added docs, i have not checked.

Helma posted late last night that these had been removed. Not sure when 
you generated this locationmap.

Ross

Re: [DOCS] Building for release - update

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ross Gardler wrote:
> There are now three possible workarounds, it's up to others to pick one 
> and go with it in order to get the release out:

Why can't we write locationmap.xml and supply it to Forrest instead of torturing 
Daisy's navigation doc & Forrest Daisy plugin? Would it work?

Attached is my take on locationmap.xml, mostly removing path fragments. Results 
are encouraging - now diff between old URI space and new version is much smaller 
(attached as well)

Note that there are several numbered docs in there - either mislabelled old docs 
or newly added docs, i have not checked.

Vadim

Re: [DOCS] Building for release - update

Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
> 

...

>>If someone else can handle the Daisy end of things I can handle to 
>>Forrest end, but probably not until Friday as most of tomorrow (GMT) is 
>>a travelling day. If anyone wants to handle the Forrest end beofore 
>>then, the above examples should be enough, if not David and/or the 
>>Forrest user list will help out I am sure.
> 
> 
> Hmmm, i have already recommended many times that we
> should not attempt this until the 2.2 release. At that
> time we can rearrange its /2.2/ URL-space.
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113150487903479

Yes, but this is another option, and may be working. I'm not sure how 
long Helma spent on it, not long I hope, it was really a series of cut 
and pastes in the daisy nav documents (and a fair amount of clicking 
through the web interface).

For my part it was only about half an hour and since Helma was so quick 
off the mark I got that done tonight. It's worth a try I think.

> I have also said that i have other commitments, so don't
> rely on me. Of course i will try to answer questions.

Yes, sorry. I should have said the Forrest user list without naming you 
explicitly.

> We should not be holding up the release any longer.
> There is a workaround, so lets do it.

+1

There are now three possible workarounds, it's up to others to pick one 
and go with it in order to get the release out:

a) The recent modifications to the Daisy navs may prove to give us the 
URL space we want, some .htaccess magic may be needed to deal with 
deeper nesting problems that Helma referred to, but that will hopefully 
be minimal now.

If that doesn't work then either:

b) go with the tarred docs I posted earlier and use .htaccess to ensure 
the old links work

c) go with the "old" 2.1.8 docs as David suggests

Ross

Re: [DOCS] Building for release - update

Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> hepabolu wrote:
> >I now also realise what happened and what the rationale was behind the 
> >way it is currently set up in Daisy:
> >
> >the main menu bar suggests that there are sub sections: About, 
> >Documentation, Community etc. I wanted to keep that division so I 
> >created the "folders" About, Documentation, Community etc. I focused 
> >more on the appearance of the menu on the left than on the urls. When 
> >there was a discrepancy, I choose the menu above the url.

One of Cocoon's features is that it disconnects the
URL-space from the filesystem and enables changes
to not affect the URLs. To break that would make us
look foolish.

> >So, I can either remove the "headers" like About and Documentation and 
> >they have to be added in the daisy-to-forrest conversion, or we have to 
> >settle for a slightly adjusted url space.

If they are truly only minor changes, then we
could use Apache httpd .htaccess redirects.

Or we follow the previous plan, which ensures that we
don't mangle the URL-space.
cocoon.apache.org/1.x/
cocoon.apache.org/2.0/
cocoon.apache.org/2.1/
cocoon.apache.org/2.2/
cocoon.apache.org/ ... top-level as a separate set of documents
that are not specific to any particular release, e.g. livesites.

> If someone else can handle the Daisy end of things I can handle to 
> Forrest end, but probably not until Friday as most of tomorrow (GMT) is 
> a travelling day. If anyone wants to handle the Forrest end beofore 
> then, the above examples should be enough, if not David and/or the 
> Forrest user list will help out I am sure.

Hmmm, i have already recommended many times that we
should not attempt this until the 2.2 release. At that
time we can rearrange its /2.2/ URL-space.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113150487903479

I have also said that i have other commitments, so don't
rely on me. Of course i will try to answer questions.

We should not be holding up the release any longer.
There is a workaround, so lets do it.

-David

Re: [DOCS] Building for release - update

Posted by Ross Gardler <rg...@apache.org>.
hepabolu wrote:
> I now also realise what happened and what the rationale was behind the 
> way it is currently set up in Daisy:
> 
> the main menu bar suggests that there are sub sections: About, 
> Documentation, Community etc. I wanted to keep that division so I 
> created the "folders" About, Documentation, Community etc. I focused 
> more on the appearance of the menu on the left than on the urls. When 
> there was a discrepancy, I choose the menu above the url.
> 
> So, I can either remove the "headers" like About and Documentation and 
> they have to be added in the daisy-to-forrest conversion, or we have to 
> settle for a slightly adjusted url space.

It is too complex to have Forrest rebuild the navigation structure in 
that way, but it does given me an idea for something that I believe is 
manageable.

If we split the navigation document in Diasy into subsections, i.e. at 
the point at which the extra URL entries appear, we can then import 
those into Forrest's site definition file at the relevant point.

So, in Forrest (site.xml), we currently have::

<xi:include href="cocoon://daisy.site.655"/>

(document 655 is the current, all encompassing navigation document)

this is replaced with

<about label="About">
   <xi:include href="cocoon://daisy.site.ABOUT_NAV_SECTION"/>
</about>
<documentation label="Documentation">
   <xi:include href="cocoon://daisy.site.DOCUMENTATION_NAV_SECTION"/>
</documentation>
etc.

This should work without any modifications to the Forrest plugin.

A nice side effect is that it will result in a smaller, more manageable 
navigation structure in Daisy whilst (I think) the complete nav document 
can be reconstructed in Daisy using import nodes in much the same way as 
in Forrest above. We may even be able to use this to recreate the 
site.xml file in Forrest, but if not hand coding in Forrest will be a 
quick fix for this release.

If someone else can handle the Daisy end of things I can handle to 
Forrest end, but probably not until Friday as most of tomorrow (GMT) is 
a travelling day. If anyone wants to handle the Forrest end beofore 
then, the above examples should be enough, if not David and/or the 
Forrest user list will help out I am sure.

Ross