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.
What do you think about the following idea:
- Each block has the same structure as it has now, so we just move things.
- We don't care which build system is used to build a block.
- The result of a block build is a war file (cocoon block archive)
- We change *our* blocks to use maven
- We provide a simple deploy tool (ant task, maven plugin whatever) that takes a cocoon block archive and simply extracts it's content into the webapp directory (libs go to WEB-INF/lib etc.) - No hot deployment for now.
- We require that each block has a configuration file for components that is in the xconf directory and this file is named "BLOCKNAME.xconf".
- The component configuration file includes all "*.xconf" files of the blocks required - no auto configuration for now.
- Each block has an own gump descriptor and we could use this descriptor to add the dependencies to the xconf.
- We provide a simple possibility that builds all available blocks (like we do today) and deploys them into the webapp. This ensures that apart from checking out, building a full cocoon (or a version with selected blocks) is still as easy as it is today.
I think these are minimal changes that can be done very quickly.
Using own blocks is simple as well: build an archive and use the deploy task.
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.
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.
WDYT?
--
Reinhard P�tz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}web(log): http://www.poetz.cc --------------------------------------------------------------------
