cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <>
Subject Re: [vote] Forrestizing Cocoon and more
Date Wed, 26 Mar 2003 10:19:04 GMT

On Wed, 26 Mar 2003, Stefano Mazzocchi wrote:

> David Crossley wrote:
> > Stefano Mazzocchi wrote:
> >>1) we remove all the old docs targets from the build
> >
> >
> > To remove the "build docs" target, i agree.
> > To remove the webapp docs generation, i do not agree.
> Ok.
> >>2) documentation will be done thru forrest. This requires forrest be
> >>available on the machine separately. since users won't update the
> >>documentation this should not be a problem.
> >
> >
> > But we do want to encourage the users to update doco and send
> > patches. So i would not use them as an excuse.
> I'm not finding excuses, David, I'm trying to move this shit forward and
> the dependencies between cocoon and forrest are *SO* interconnected that
> I could not find a solution to the problem.
> Moreover, to be honest, I think that we should aim to improve
> forrest/lenya and make it a structured wiki and setup a CMS and point
> users to that for editing.
> that's the only way they can help up writing docs because our current
> xdocs-patch workflow is too much a stinking pain in the ass.


> >>3) we ship the pregenerated documentation in the distribution and we
> >>ship along the xml source files. if the documentation is included in the
> >>webapp cocoon will simply *read* them (not process them as right now).
> >
> >
> > Why would you want many megabytes of generated docs
> > in the cvs? This seems to defeat the purpose of Cocoon.
> > Surely there is a way for Cocoon to continue to generate
> > its own doco via its webapp.
> yes, there is: ship forrest skins and xml/xslt machinery with cocoon.

The forrest target creates a context before producing the docs. Can't we
moving this context into the webapp? Perhaps a possible solution?


View raw message