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
