cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BURGHARD √Čric <>
Subject Re: Cocoon 2.1.x - Build and deployment with Maven2
Date Mon, 05 Dec 2005 17:39:18 GMT
> It's not *one* jar, an important feature of the bricks-cms build is
> picking up required blocks, and compiling only those. Later, the build
> applies the required *.x* patch files to the Cocoon configs, as is
> currently required in 2.1.x. An alternate build must handle all of
> this, in addition to compiling the app's code, of course.

Ok. I miss that feature. But that's why it's so complicated to build a
project on top of cocoon: you need the sources.

Before m2 i used to do quite a similar thing but less automated: a
svn:externals on cocoon inside my project (to link my app with a cocoon
revision), an ant build process that copy the local properties, build
cocoon, and finally copy the various jar and conf in my webapp. I missed
the patching of files coz i used the include feature (is this a 2.2-dev
only feature ?), so the number of file to modify and the amount of
modification are minimal.

> Are you suggesting splitting the bricks-cms build in two?
> 1) First part compiles the required blocks and puts the corresponding
> jars into an m2 repository
> 2) Second part uses m2 to compile bricks-cms against these blocks,
> applies the xconf patches, etc.

I mean that all cocoon jars are putted inside a m2 repository, and that your
brick-cms just declare them in his pom. There is effectively a problem with
the xconf and sitemap-additions, but i think you can package them somehow
in maven artifacts like cocoon-xxx-conf (resources jar). Then we just had
to write a maven plugin that unpack, patch ?, and copy the conf files in
the right places during the copy-ressources phase. dependencies between
blocks and conf are described in poms.

All 'dynamic' selection of blocks and 'build' stuff would disapear from your
brick-cms, and only remains the usefull stuff that show to new users how to
use cocoon and not how to construct it.

You don't need the source to build a cocoon based app, and you don't have to
have a special kind of hot-pluguable block to handle the componentisation.
Regular jar are just sufficient and it could work with every existing
cocoon release.

> If this is possible without completely mavenizing 2.1 it might be cool
> - but I'm not sure if this is what you mean. But I think the problem
> involves more than putting a cocoon 2.1.x jar in an m2 repository.

My app is working like that, but i must admit that i had manually copy the
conf files in various place.

Because you already wrote all the patching stuff and because i wrote a
groovyc plugin for maven that make the conversion of ant based build
process to maven plugins pretty easy, we could quickly have something
really user-friendly without redesigning everything.



View raw message