cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [2.2] Past, present and future of the maven build
Date Tue, 30 Aug 2005 15:31:46 GMT
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.


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
>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

View raw message