cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject unstable blocks (was: [VOTE] Move javaflow into scratchpad)
Date Tue, 30 Mar 2004 09:19:25 GMT
On 30.03.2004 10:33, Bertrand Delacretaz wrote:

> I like the idea, and it's easy to do as blocks.properties are generated 
> from gump.xml.

Indeed.

> Problem is, this means shipping with many blocks disabled. I think this 
> would warrant a notice at the top of the "blocks with samples" page, 
> something like "see blocks.properties for a list of all available blocks".

IMO having blocks disabled is not a problem. But the way re-enabling 
them is. It's no longer possible to tell the user "copy 
blocks.properties to local.blocks.properties and edit this one". I 
already had this issue when only including woody block after deprecation.

So when doing it - what it is a good thing - we have to change the build 
process in relation to blocks selection. Isn't it possible to switch to 
include.block.{blockname}={true|false} syntax as this property is not 
used directly in blocks-build.xml, but mapped to a property 
unless.exclude.block.{blockname} at the moment:

<condition property="unless.exclude.block.fop">
   <istrue value="${exclude.block.fop}"/>
</condition>

Doing the mapping in another should not be impossible, allows us to use 
the more intuitive notation proposed above and removes the need for 
adding blocks.properties at all.

Joerg

Mime
View raw message