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.
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.
+1
--
Stefano.
