Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43C505DB.4030202@nada.kth.se>
Date: Wed, 11 Jan 2006 14:19:23 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: [M10N] GroupId for blocks and layering of Cocoon
References: <20060110182806.13287.qmail@minotaur.apache.org>
 <43C40D0A.4090003@mobilebox.pl> <43C4151D.2010300@nada.kth.se>
 <43C41879.1090308@apache.org>
 <Pine.LNX.4.64.0601102157280.7472@lapgp.otego.com>
 <dq2k3k$6p3$1@sea.gmane.org> <43C4D657.1040308@nada.kth.se>
 <43C4DB60.6080507@apache.org>
In-Reply-To: <43C4DB60.6080507@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Was: Re: svn commit: r367714 - in /cocoon/trunk/cocoon-template: ./   
pom.xml src/ src/main/ src/test/

Carsten Ziegeler wrote:

>Daniel Fagerstrom schrieb:
>  
>
>>Jorg Heymans skrev:
>>    
>>
>>>Giacomo Pati wrote:
>>>      
>>>
>>...
>>    
>>
>>>Each block should have the same groupId yes. Should we make it
>>>o.a.c.blocks ? (in analogy with [1])
>>>      
>>>
>>Everything will be a block, the core included, in analogy with [2]. So 
>>it would be redundant to introduce an extra level in the groupId.
>>
>>    
>>
>Hmm, don't we need some "bootstrapping", for example the cocoon servlet
>or the cli main class etc? I think these are not really blocks. Even if
>they are from an implementation pov, they are not from a functionality
>pov. So personally, I would distinguish between blocks and
>"bootstrapping" which could be core.
>  
>
One of the goals from the NG discussions during the end of the last year 
was to make Cocoon less monolithic, and make it easier to reuse parts of it.

At the top layer in an layered Cocoon architecture I envision that we 
have "controllers" (that implement Servlet). The controller chain for 
large Cocoon systems would be:

  BlocksManager -> BlockManager -> [SitemapServlet | FlowscriptServlet | 
JavaFlowServlet | ... ]

In a small application with less need for modularization the controller 
chain might be just:

  FlowscriptServlet

If we want the different controllers to be reusable it makes less sense 
to consider one of them a bootstrap layer.

The blocks framework is under refactoring to implement this vision.

                                   --- o0o ---

Until things has settled a little bit more I suggest that we keep the 
current flat layout with o.a.c as GroupId.

I also think that GroupId should reflect community structure rather than 
function. If we start to grow as a community and get clear sub 
communities that work on disjunct set of artifacts, it would make sense 
to have a more fine grained GroupId structure.

/Daniel