Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 97836 invoked by uid 500); 25 Mar 2003 15:43:59 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 97791 invoked from network); 25 Mar 2003 15:43:57 -0000 Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65) by daedalus.apache.org with SMTP; 25 Mar 2003 15:43:57 -0000 Received: (qmail 22801 invoked from network); 25 Mar 2003 15:43:49 -0000 Received: from unknown (HELO apache.org) (stefano@80.105.91.155) by pulse.betaversion.org with SMTP; 25 Mar 2003 15:43:49 -0000 Message-ID: <3E80794C.6030807@apache.org> Date: Tue, 25 Mar 2003 16:44:12 +0100 From: Stefano Mazzocchi User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [vote] Forrestizing Cocoon and more References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Stephan Michels wrote: >>So, at the end, here is what I propose: >> >>1) we remove all the old docs targets from the build >> >>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. >> >>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). >> >>4) this breaks the flow samples that depend on those stylesheets but >>they are going to be refactored anyway, so don't worry. >> >>5) finally, remove all the doc-generation stylesheets from the CVS >> >>what do you think? > > > So, I have converted all xdocs to v11, and wrote a sitemap, which > delivers the static content. But now I have the following problem that > every time I make a webapp all docs must be rehandled :-/ just set exclude.webapp.documentation=true in your local.build.properties file. > I think it is the best to separate these things complete. > > webapp -> create a webapp with samples or a clean webap. > docs/forrest -> create the static docs. > > BTW, I see much projects, which delivers more than one webapp, perhaps > it's a solution to offer two war's: cocoon-samples.war, cocoon-clean.war ? Nah, the build is already configurable enough. If you don't want the docs (or the samples, or the javadocs or the IDLdocs) just don't include them in your webapp build. Stefano.