Return-Path: Delivered-To: apmail-xml-cocoon-docs-archive@xml.apache.org Received: (qmail 92646 invoked by uid 500); 19 Feb 2003 07:29:07 -0000 Mailing-List: contact cocoon-docs-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-docs@xml.apache.org Delivered-To: mailing list cocoon-docs@xml.apache.org Received: (qmail 92637 invoked from network); 19 Feb 2003 07:29:06 -0000 Received: from smtp-relay02.tc.dsvr.net (212.69.192.6) by daedalus.apache.org with SMTP; 19 Feb 2003 07:29:06 -0000 Received: from [212.69.205.254] (helo=codeconsult.dsvr.co.uk) by smtp-relay02.tc.dsvr.net with esmtp (Exim 4.12) id 18lOfN-0002Du-00 for cocoon-docs@xml.apache.org; Wed, 19 Feb 2003 07:29:17 +0000 Received: from codeconsult.ch (lsb-catv-1-p211.vtxnet.ch [212.147.5.211]) by codeconsult.dsvr.co.uk (8.11.6/8.11.6) with ESMTP id h1J7THh07395 for ; Wed, 19 Feb 2003 07:29:17 GMT Date: Wed, 19 Feb 2003 08:29:17 +0100 Subject: Re: [PROPOSAL] Use Forrest to build Cocoon docs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Bertrand Delacretaz To: cocoon-docs@xml.apache.org Content-Transfer-Encoding: quoted-printable In-Reply-To: <1045627920.21241.12153.camel@ighp> Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Le Mercredi, 19 f=E9v 2003, =E0 05:11 Europe/Zurich, David Crossley a = =E9crit=20 : > ...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=20 versions) would be confusing for users and a waste of energy for=20 contributors. As we're going to use Forrest, I'd generate all docs with Forrest and=20 remove the existing standalone stuff. Technically I think this requires having a binary version of Forrest in=20= our CVS, used as a blackbox tool to generate the docs. It won't help=20 make our CVS codebase smaller, but is there another way? This is really=20= what we want to do conceptually, use Forrest as a stable tool for our=20 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=20 admit some uncertainty about exactly what is required to move our docs=20= to Forrest, which made me even quieter than I should have been. I'm=20 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=20 required IMHO) to the CVS, in /tools -using a separate build.xml (called from the main one) to build the=20 docs using Forrest -doing this on a CVS branch until the Forrestized docs are usable Whaddyathink? -Bertrand=