Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 2279 invoked by uid 500); 28 Feb 2003 11:57:36 -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 2172 invoked from network); 28 Feb 2003 11:57:35 -0000 Received: from anchor-post-34.mail.demon.net (194.217.242.92) by daedalus.apache.org with SMTP; 28 Feb 2003 11:57:35 -0000 Received: from media.demon.co.uk ([80.177.14.141]) by anchor-post-34.mail.demon.net with esmtp (Exim 3.35 #1) id 18oj8w-000Ncc-0Y for cocoon-dev@xml.apache.org; Fri, 28 Feb 2003 11:57:34 +0000 Date: Fri, 28 Feb 2003 11:57:35 +0000 Subject: Re: [New build system] Status of samples Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Jeremy Quinn To: cocoon-dev@xml.apache.org Content-Transfer-Encoding: 7bit In-Reply-To: <3E5F3EEA.3060704@apache.org> Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Friday, February 28, 2003, at 10:50 AM, Stefano Mazzocchi wrote: > Finally, I think the Cocoon build should also allow you to build your > own cocoon web site. In this case, your stuff should becomes nothing > different from a microblock. (please, don't start using this > terminology, it sucks, it's just to give you the idea) > I completely agree. (but I have no suggestions for a solution, sorry) One of the trickiest things to do with Cocoon is to update an existing webapp with a new version of the code and configs. The configs pose the largest problem. 1) they change often, 2) you often have to modify them with your own datasources (etc.). While it is important to have a simple build, so you can see it works out of the box (as we have now), I am looking at the scenario whereby a user wants to update an existing cocoon installation with a fresh update from CVS, first for testing, then for production. Or wants to build an installation of samples. so I see 4 common scenarios : 1) a 'test' build and run (we have that and it's great!) 2) a 'samples' build and run 3) an 'update' build and run (on an internal testing port) 4) an 'update' build and run (on a production port) Where the 'update' build will build _into_ an existing webapp, or for testing, build _using_ an existing webapp. (Where 'webapp' obviously means the set of sitemaps/xslt/xml etc.) I am sorry I do not actually have any solutions, I am just thinking about what I reckon people want to be able to do easily. Thanks for all the hard work you are putting in. regards Jeremy