A word of caution. One thing we ran into with Maven 1 was that we ended
up splitting individual components into 3 parts; api, impl and test. As
you start moving from one monolithic project into smaller subcomponents
which are compiled separately you will soon find that you have
circularity problems. The only good way to solve this is to use lots of
interfaces. To some degree we already see this today where we have
blocks depending on each other. Test is split off because very often the
runtime dependencies are different than the compile-time dependencies.
In addition, the Cocoon samples often introduce dependencies that the
core code of the project or even the test cases don't need.
So to summarize, I would suggest that it would be a good idea for each
"component" - be it core or a block - to have api, impl, test and
samples projects.
Ralph
Carsten Ziegeler wrote:
As posted recently we are now able to use m2 to build the core.
Now what does this mean?
Currently we have one maven project, Cocoon, with two sub projects: core
and webapp. The core contains all classes of the cocoon.jar and the
corresponding junit tests. m2 is able to compile the classes, run the
tests and create a jar file with the classes and resources (nothing
really surprising here).
The webapp subproject contains all resources for the webapp (web.xml,
root sitemap etc) and all samples of the core (though some of them are
not working as reported). m2 is able to build the webapp including all
required jars etc.
So what is left? (This list is not complete)
1. Splitting up the core
As discussed in several threads we should create more subprojects,
perhaps something like (let's not discuss the names please, just the
structure)
cocoon + core - The real core (treeprocessor, ecm++, flow)
+ environments - servlet - The servlet environment
- cli - The cli environment
+ modules - cforms
- cauth
- ctemplate
- standard components (file generator and co)
+ webapp - the webapp without samples
+ samples - all basic samples
We can start with a simple(r) structure and create subprojects on
demand. This is very easy with m2: create a new sub project, at the
dependency to the other(s) projects and that's it.
Each block gets a similar structure
blockx + core - the real block
+ webapp - required webapp part like configuration etc.)
+ samples - the samples
Splitting up the current code base into a structure like this is just
moving directories and files. So that's really easy.
I think we should then write a little m2 plugin that deploys a block
into a build webapp:
- jars are copied to WEB-INF/lib
- configuration to WEB-INF/xconf
- other resources are copied as well
- new sitemap components are added to the main sitemap
- optional: samples are copied
Doing this is imho very easy, these are some small steps and we will
have a running 2.2 again with several subprojects that can be used
independently.
Carsten
