cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [2.2] Past, present and future of the maven build
Date Tue, 30 Aug 2005 19:19:16 GMT
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)

Java script flow could also be move to an own block. Only the flowscript 
interfaces need to be part of core.

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


At a later point we should probably have one block (bundle) for each 
item above.

> 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

Factoring out the samples is good but I don't understand the split into 
core and samples, care to explain?

> 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

Can't this be handled by wildcard inclusion from component 
configurations in some catalog, so that we get rid of the snippet 

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

In another mail youn said:

> Anyway, if we split up the core into several parts,
> this will break the Ant build script. Of course we could now change the
> ant script as well, but that's imho
> to much energy put at the wrong place.

What about starting to get the blocks compiling with m2 before starting 
to split the core, then we minimaize the time when not the complete 
Cocoon compile.


View raw message