Joerg Heinicke wrote:
IMO this is difficult to maintain. If someone wants to look on the code base of a block he has to search for its dependencies first or search for the code at different places. Can't we extract the blocks from 2.1 "as they are" at the moment and move them to cocoon-blocks module, so that they are collected at one place.
to be clear: I'm not against this, but only after people realize the problems that might come up and we come up with consensus on how we are going to deal with those problems *when* they come up
Not if, because you can bet that over-blockization is going to happen... or, at least, asked for.
As it is today, blocks are not only modular packages to extend cocoon (as fop and batik, for example, who triggered the creation of the fake block system), but also a way to propose new stuff as one-man-shows.
I fear one-man-shows.
At the same time, we need 'sort-of incubation' practices for blocks, as it is impractical to think that a cocoon committer would develop his/her code outside and submit it only when there is a community around a block.
the block system will work effectively *ONLY* if there is strong cross-pollination between blocks and if the cocoon community keeps strong oversight over what happens.
this hasn't been so for many blocks so far and I see this as a potential problem.
So it's a community issue on the one hand and a "we do not know which problems could be arise" on the other hand. The first thing we can of course handle now, the other thing we will see ...
Joerg
