...For example, how does the Cocoon webapp continue to work with the new documentation v11 format. I expect that all the documentation stylesheets and documentation/sitemap.xmap need to change too.
IMHO maintaining both sets of documentation (Forrest and non-Forrest versions) would be confusing for users and a waste of energy for contributors.
As we're going to use Forrest, I'd generate all docs with Forrest and remove the existing standalone stuff.
Technically I think this requires having a binary version of Forrest in our CVS, used as a blackbox tool to generate the docs. It won't help make our CVS codebase smaller, but is there another way? This is really what we want to do conceptually, use Forrest as a stable tool for our docs.
...The last time we started raising the associated issues, everyone went quiet for many months.
On my part it is mainly due to events unrelated to Cocoon, but I must admit some uncertainty about exactly what is required to move our docs to Forrest, which made me even quieter than I should have been. I'm probably not alone in this case.
...At some stage we need to just do the once-off conversion, and then pick up the pieces.
Yes. Going concrete would certainly help, so how about:
-adding a binary version of Forrest (including Cocoon, weird but required IMHO) to the CVS, in /tools
-using a separate build.xml (called from the main one) to build the docs using Forrest
-doing this on a CVS branch until the Forrestized docs are usable
Whaddyathink?
-Bertrand
