Carsten Ziegeler wrote:
2. Move blocks to one location. /repos/asf/cocoon/trunk/blocks?
yes
3. Separate blocks build system from core build system and let one drive the other.
Comments?
Some thoughts I want to share:
goal: move towards real blocks - do as much work that can be reused later
- each block has its own build system
- each block has a public and a private directory
- each block has a deployment descriptor:
* list of blocks that are necessary to make them compile/run
* list of blocks that are necessary at runtime
(e.g. forms needs xsp because of the examples)
* list of all libraries
(all libraries are in a single Cocoon library repository
and this way we can make sure that we don't end at jar hell
--> real block and their shielding will finally solve this)
--> create gump file
--> create eclipse/idea project files
- each block only depends on
- cocoon core
- public sources of other blocksa complete build runs through following steps:
- compile Cocoon core - one build task that compiles all public directories at once (or can we make sure that there are no circular dependencies, which should be avoided of course) - compile each block separatly - create web application - deploy each block separatly - copy samples - patch configuration files
but of course only a single block can be deployed too
It's probably a lot of work but sooner or later we have to do it anyway, so why should we suffer from our build system and a gigantic eclipse project any longer
-- Reinhard
