...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....
Because the current detection is based on the presence of the "exclude.block.xyz" rather than its value, is that right?
I guess this was "once upon a time". The current version even allows exclude.block.xyz=false and handles this the same way as the property would not be there because of the
<condition>
<istrue/>
</condition>
construct. So it's more a bad documentation at the moment. Quote from blocks.properties: "Remove blocks from your cocoon distribution by uncommenting the corresponding exclude property."
...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...
I'd be +1 on this, "include.block.xyz" makes more sense.
We can do it with changed documentation using exclude.block.xyz=false. As local.blocks.properties is loaded before blocks.properties and properties can not be reset, this would work.
I personally prefer the other way around: include.block.xyz - including the consequences of forcing users to recopy the blocks.properties and resetting their blocks selection.
I already have the include way working. It's backward compatible as long as the exclude=false is not already used.
WDYT? Change only the documentation (to "use true|false") or additionally the property names from exclude to include.
Joerg
