cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robby Pelssers <>
Subject RE: parent of parent artifact?
Date Thu, 08 Mar 2012 21:26:47 GMT
Hi Lars,

That is fair to say indeed.  In this case the cocoon instance you are referring to is the
cocoon-servlet which is the main engine for any cocoon webapp.

I am not entirely sure though if the applications you refer to can be considered similar to
the cocoon-blocks.  Although you mount them in a Uber sitemap, I don't think you can invoke
services from 1 to another sitemap in 2.1.x versions of Cocoon although that could be best
answered by the elder Cocoonistas ;-)

Have you ever heard of a WAR overlay?  You could also compare a cocoon app in some sense to
this principle where the final WAR (webapp) is the result of merging all dependencies (cocoon-blocks).
 But it's not really the same though.

A cocoon block typically (but optionally) consists of
 - resources (css / js / ...)
 - Java components
 - Spring application context (where you configure your beans)

It's like LEGO. You build isolated blocks (modules) of functionality but blocks can reuse
each other (by declaring dependencies on each other).

In the final webapp project you include the blocks you need and you package it all together
into a war. 

That's the global idea.


-----Original Message-----
From: Lars Huttar [] 
Sent: Thursday, March 08, 2012 10:10 PM
Cc: Robby Pelssers
Subject: Re: parent of parent artifact?

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.

Is it fair to say that a Cocoon "web app" corresponds to one instance of 
Cocoon running? So a "web app" can consist of several blocks?


On 3/8/2012 12:22 PM, Robby Pelssers wrote:
> Hey Lars,
> Great you ask these questions actually and I will try to answer to my best knowledge.
> * First of all your understanding of maven archetypes is completely correct.  A maven
archetype is a project that creates a folder structure on your file system where the archetype
itself contains some default resources like e.g. a partially prefilled pom.xml and so on.
> * There is no need to declare any dependency on a cocoon block actually. But since version
2.2 Cocoon uses the servlet service framework.  I would compare a cocoon-block to a sub-webapp
potentially providing some Java components and pipelines which can be invoked from another
> To give a concrete example.  At my customer I created 1 cocoon-block called 'shared'
which provides services to fetch files from a XMLDB, Alfresco, file system.  As customer requirements
grew, I created other blocks delivering needed functionality but they all need and use above
described services. So in that case I only needed to declare a dependency on this 'shared'
> That enables me to call this service from another sitemap as e.g.<map:generate src="servlet:shared:/alfresco/{1}"/>
 where {1} is some file identifier.
> * Project / module / archetype and artifact are typical maven terms.
> - Project should need no explanation
> - module can be described as a part of the project
> - archetype is explained above
> - artifact is the thing that gets build when you run mvn package  (a war, jar, ...)
> As a end user you should not be creating archetypes, merely using them as shown in the
previous mails. It will generate some skeleton maven projects for you.
> Any further questions?
> Robby

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

View raw message