Return-Path: 
 <dev-return-58776-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 40418 invoked from network); 2 Apr 2004 14:29:01 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 2 Apr 2004 14:29:01 -0000
Received: (qmail 27885 invoked by uid 500); 2 Apr 2004 14:28:53 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 27842 invoked by uid 500); 2 Apr 2004 14:28:53 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 27827 invoked from network); 2 Apr 2004 14:28:53 -0000
Received: from unknown (HELO out2.smtp.messagingengine.com) (66.111.4.26)
  by daedalus.apache.org with SMTP; 2 Apr 2004 14:28:53 -0000
X-Sasl-enc: Wif3M6QE8ZxJbu9YPF/S+w 1080916133
Received: from upaya.co.uk (unknown [213.48.13.39])
	by www.fastmail.fm (Postfix) with ESMTP id 9C1E2912B1C
	for <dev@cocoon.apache.org>; Fri,  2 Apr 2004 09:28:53 -0500 (EST)
Message-ID: <406D7878.3090407@upaya.co.uk>
Date: Fri, 02 Apr 2004 15:28:08 +0100
From: Upayavira <uv@upaya.co.uk>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: excluding unstable blocks by default
References: <200404011300.i31D03O26562@otsrv1.iic.ugent.be>
 <406C52DC.6080209@gmx.de>
 <F1E75B4C-8441-11D8-8B53-000A95908E0E@wrinkledog.com>
 <406D425B.9040904@upaya.co.uk> <loom.20040402T154810-513@post.gmane.org>
In-Reply-To: <loom.20040402T154810-513@post.gmane.org>
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
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Joerg Heinicke wrote:

>Upayavira <uv <at> upaya.co.uk> writes:
>
>  
>
>>How hard would it be to switch to having:
>>
>>build stable
>>or
>>build unstable
>>
>>instead of build webapp?
>>
>>That would enable someone to choose right up front, without having to do any
>>file editing.
>>    
>>
>
>Hmm, that's indeed an interesting approach IMO. I thought about something
>similar (creating blocks.properties on the fly) months ago, but I stopped as the
>user would no longer have a base for starting with his blocks selection
>settings, i.e. no easy way like "copy blocks.properties to
>local.blocks.properties".
>
>With the current implementation a simple build stable/unstable would not work.
>You must ignore local.blocks.properties for getting this working.
>
>But the above also leads to new idea: First remove blocks.properties from CVS
>and the need for local.blocks.properties, both files will not be read in the
>init target. The information stable/unstable is in gump.xml and blocks-build.xml
>is created from it, so we don't need the indirection using blocks.properties.
>
>Now build stable and build unstable influence the creation of blocks-build.xml.
>Sounds not very difficult IMO.
>
>Now I want to complete this picture:
>build (minimum) webapp <== just Cocoon core
>build stable webapp <== Cocoon core + stable blocks
>build unstable webapp <== Cocoon core + stable + unstable blocks
>build complete webapp <== Cocoon core + stable + unstable + deprecated blocks
>
>I also would ignore the backwards incompatibility: We can print out on build
>time what is chosen, furthermore I think it's very obvious when build webapp
>does no longer include your selected blocks, everybody will get this very fast.
>
>And for a custom blocks selection there is additionally
>build custom webapp
>This target would look for a local.blocks.properties (or
>custom.blocks.properties for consistency with the target). If it's not there it
>generates it, stops the build and asks the user for doing the selection in this
>file. A further call to the target would execute the build completely.
>
>BTW, if you only introduce build stable/unstable, mapping one or the other to
>build webapp, then you can not build the war file with the same
>behaviour/default selection of stable/unstable blocks.
>
>WDYT?
>  
>
Reads great to me. Much better. I like the way you've got a 'core only' 
option in there. Thoughts from others?

Regards, Upayavira