Reinhard Poetz wrote:
Carsten Ziegeler wrote:
The more I think about it, I come to the conclusion that moving the blocks out of the core seems to be a good way to procede.
(Moving files with SVN is easy and the history etc. is preserved).
(Of course we should only move things for 2.2 - 2.1.x should be left untouched)
Now one benefit of course is that our core gets smaller, but that's not really a reason to move things.
But if we move the blocks, we *have to* think about a simple but working solution for configuration and dependencies.
<snip/>
Look at http://svn.apache.org/repos/asf/cocoon/whiteboard/block-builder/, which provides nearly everything you describe above. Additionally it resolves dependencies between blocks which makes it possible to work on a single block without taking care of other, non-related blocks.
The only prerequisite is a descriptor file like block.xml that consists of
- general meta information (author, license, ...) - required blocks - required libraries
block.xml is versioned by a doctype like http://apache.org/cocoon/blocks/1.0. This information isn't useful right now but will help the future Block*Deployer* to indentify if a block and a Cocoon core version fit together.
If nobody objects I would setup the BlockBuilder for Cocoon 2.2 and for the portal block (+ all blocks it depends on) over the next weekend. Afterwards we can evaluate if _we_ like it or not.
Please go ahead, and if you and Carsten can agree about how to do it, its even better.
Anyone who dare to step forward and move out the blocks from the trunk will become my personal hero, be nominated by me for "the employe of the year", and maybe even get a beer at the real blocks hackaton ;)
Until now I've hesitated to propose using the BlockBuilder because I've thought that it requires a fully useable deployment tool. But if we follow Carsten's idea of a simple deployment tool (unpacking) this isn't a problem any more.
JFDI!!!
--- o0o ---
Sometimes I think that "real blocks"
[...] is another instance of something that is becoming an anti-pattern: "stating the solution before stating the problem".
(Sorry for using citations in such an unfair way ;) )
Now, don't get me wrong. I belive that the block concept is a beautiful design and that we eventually will need all aspects of it. But we should sometimes remind ourselves about what problems we actually are trying to solve, identify whats most important, focus on that, and then try to find "the simplest thing that could possibly work".
So which problem is the most important?
IMO our huge community problem is what is most important. No, I'm certainly not talking about our excelent existing community, I'm talking about the fact that we only elected two new committers during 2004, compare that to around ten during 2003, and probably similar figures the years before that. Are our requirements on new committers to high? Maybe, maybe not, I think the standards have been high all the time.
I think it is our code base that is the main threshold for newcommers to start contributing. The core probably both will and must be a task for highly dedicated experts. But the threshold for creating a successfull block is much higher than it should be for non committers.
Think about an entusiastic non-comitter who starts to develop a new cool and really usefull block at e.g. Sourceforge. Will it have the chance to attract lots of users? I helped with "blockifying" Fins, it resulted in a +10 step instalation guide http://www.sidimar.ipzs.it/fins012/docs/install.html, that probably looks scary for many potential users.
Now, moving out the block out of core will force us to make it easy to use externaly defined blocks. And that will make it much easier and more atractive for "outsiders" to develop blocks. And that will grow the community in a healthy and scalable way. It will also make the rest of "real blocks" (or maybe something else), a real itch to scratch and not just something that would be nice to have. I also believe that it will make us more motivated to make the core "lean and mean".
--- o0o ---
So just throw the blocks out of core, we can solve the possible problems when and if they apear ;)
/Daniel
