Return-Path: Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org Received: (qmail 39014 invoked by uid 500); 8 Aug 2002 09:11:58 -0000 Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: forrest-dev@xml.apache.org Delivered-To: mailing list forrest-dev@xml.apache.org Received: (qmail 39005 invoked from network); 8 Aug 2002 09:11:57 -0000 Received: from mail-4.tiscali.it (HELO mail.tiscali.it) (195.130.225.150) by daedalus.apache.org with SMTP; 8 Aug 2002 09:11:57 -0000 Received: from apache.org (62.10.51.97) by mail.tiscali.it (6.5.026) id 3D5215210000CD90 for forrest-dev@xml.apache.org; Thu, 8 Aug 2002 11:12:09 +0200 Message-ID: <3D5235C7.7070206@apache.org> Date: Thu, 08 Aug 2002 11:11:35 +0200 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: forrest-dev@xml.apache.org Subject: Re: Proposal: Inclusion of CocoBlog in scratchpad References: <3D522DD8.9010807@cbim.it> 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 Status: O X-Status: X-Keywords: Ugo Cei wrote: ... > Steven: > > > CocoBlog could be the prime example of a drop-in Cocoon application > > (dare I say 'block'?). If we add it to the distribution, we miss the > > opportunity of showing off plug&play installation of a Cocoon-based > > app. > > The problem is I don't see a real plug&play feature coming to Cocoon > very soon. So we have tow options: > > a) I continue to distribute CocoBlog as a full application that comes > with its own Cocoon version, just like I'm doing on SourceForge > b) I distribute CocoBlog as a not-so-plug-and-play Cocoon "block" and > leave it to users to plug it inside their copy of Cocoon. > > What I'm proposing here instead is > > c) we include CocoBlog in scratchpad and when we get blocks, we refactor > it out. > > But listen, I don't want to insist too much. As I write above, I have my > own doubts about this move and own much of this proposal to the gentle > pressure of the people I quoted. I have a solution that could make all happy. Let's make a cocoon-apps CVS repository that can trigger the compilation of Cocoon by assuming that the cocoon2 CVS is checked out in the same common dir. It would make it easier also for the cleanup that's gonna take place soon. So, how does this sound? -- Nicola Ken Barozzi nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) ---------------------------------------------------------------------