> > 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. WDYT ? Regards.
