>>Reinhard Poetz wrote:
Unico Hommes wrote:
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
IIRC, Nicola already started an effort for an updated build system that features an individual build file for each block separately. I wonder what happened to that and whether it is useable already.
- each block has a public and a private directory
What does that do?
uups, I mean a public and a private source directory. Other blocks mustn't depend on private classes
- 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 blocks
This is the same file as blocks.xml for real blocks right?
Yep only stripped down for our current needs
a 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
For splitting the eclipse project there is an additional requirement that blocks and core directory don't overlap. Eclipse cannot deal with overlapping projects. So that would mean that the 2.2 core move to /repos/asf/cocoon/trunk/core .
IMO the eclipse project file for a block contains
- two source directories (public/private) - Cocon core lib - public libraries of blocks it depends on - external libraries (currently in lib/optional)
This way we don't have to deal with Eclipse project dependencies, do we?
-- Reinhard
