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. Robby -----Original Message----- From: Lars Huttar [mailto:lars_hut...@sil.org] Sent: Thursday, March 08, 2012 10:10 PM To: users@cocoon.apache.org 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? Lars 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 cocoon-block. > > 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' block. > > 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: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
