...The problem is that you have to know beforehand what blocks we want to use, compile them and -- here comes the real problem -- generate a cocoon.xconf. If you ever want to add or remove a block later on, you have to strip down the project's cocoon.xconf or merge it with the one that resulted from a new build with more blocks...
Taking a slightly different perspective here, I think both things can be parallel: for several (rather small) recent projects I've been using an application skeleton based on
http://wiki.apache.org/cocoon/YourCocoonBasedProjectAnt16, and I've found it relatively easy to add and remove blocks as needed, by editing one file, and also easy to add my own components by putting xconf files in the appropriate directory (I've also started to use hivemind as the application component manager to be decoupled from the Cocoon internals at the app level but that's another story).
I was thinking that we could add an "application seed" to SVN (in a new "contrib" directory maybe), a skeleton that allows people to build their own apps based on Cocoon, with minimal interference with Cocoon's build and blocks system. In this structure, the relevant parts of Cocoon are "pulled into" the application as needed, based on a simple configuration file which is itself built from Cocoon's configs.
IMHO this is very good for small to medium projects, and it requires little knowledge about Cocoon internals to be productive.
I'd be happy to commit a stripped-down app skeleton if people think this is useful.
WDYT?
smime.p7s
Description: S/MIME cryptographic signature
