cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <scher...@gmail.com>
Subject Re: parent of parent artifact?
Date Thu, 08 Mar 2012 21:32:22 GMT
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 you describe is like a farm, I have a customer that is hosting >300 
lenya publication in one lenya instance. However I tend to deploy each 
cocoon app as war on its own since this way scalability is easier and 
you have a finer control over each app.

Now the reason for "farming" is normally that you have common code that 
you want to use across the apps. This would be done now in your common 
block. The benefit is that you can just declare the dep and you are 
ready to use this common code.

It is important to note that consist in c3 context means "declaring deps 
to" and the war project is a simple "zombie" that distributes the work 
to the blocks.

salu2

>
> 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-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>


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

http://www.codebusters.es/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message