cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: parent of parent artifact?
Date Sat, 10 Mar 2012 00:27:13 GMT
On 03/09/2012 10:47 PM, Lars Huttar wrote:
> Thorsten,
> Thanks for this helpful reply.
> One follow-up question below...
> On 3/8/2012 3:32 PM, Thorsten Scherler wrote:
>> On 03/08/2012 10:09 PM, Lars Huttar wrote:
>>> Thanks, that's very helpful!
>>> We have a lot of  what we call "applications" that run side-by-side 
>>> under a single Cocoon 2 instance. They each live under a separate 
>>> subfolder (child of "mount/") under the main Cocoon sitemap. Each 
>>> "application" has its own sitemap.
>>> It sounds like these "applications" actually correspond to the 
>>> "blocks" you describe below.
>> They would make good candidates for blocks after all.
>>> Is it fair to say that a Cocoon "web app" corresponds to one 
>>> instance of Cocoon running?
>> web app I use actually only for packaging to deploy to tomcat.
>>> So a "web app" can consist of several blocks?
>> web app can have deps to different blocks yes.
>> However like Robby described you normally end up with the following:
>> - war block -> web app -> deb to web block
>> - web block -> block -> deb to all sub blocks (like cocoon-shiro for 
>> auth mgt, ...), providing REST services and gui
>> - common block -> block -> util, helper, cross cutting concern code
>> - dao block -> block -> connection to db (in our current customer 
>> project we use jpa over hibernate with a postgres db) providing dto 
>> for the
>> - ...
> What do the "A -> B" arrows mean here ... A has a dependency on B?

name -> type -> description/deps

As recommendation do the variant that Francesco described:
parent type contains
- one war block -> for deployment reasons only! This has normally only 
one major dep to the gui block which then has the deps to the rest.
- x functional blocks

It is not as c3 itself is organized but it is the wiser choice.

For us we have one block that is using REST services for business logic 
invocation to e.g. the dao block to persist data or the jms notification 
queue based on activemq. This blocks in our case are not even cocoon 
blocks but simple maven modules. We started to further outsource common 
pipelines to blocks on its own. In our case mails can be send from the 
REST services but as well from some jms listener block. This mails are 
generated in txt and html via a java based c3 pipelines with i18n 
support which till now had been in our web block.

However it is not that trivial to use thinks as servlet:myServlet from 
simple java projects as I am finding out. ;)


Thorsten Scherler<>
codeBusters S.L. - web based systems
<consulting, training and solutions>

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message