cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Moving configurations to core
Date Sun, 25 Sep 2005 18:46:06 GMT
Jorg Heymans wrote:

>Daniel Fagerstrom wrote:
>  
>
...

>>>From the real blocks POV it means that core would be a "component
>>block", i.e. a block that exports components (including Core) and
>>packages (especially APIs) but not sitemap functionality.
>>    
>>
>Shouldn't we make this distinction for all Blocks then, ie have
>org.apache.cocoon.lucene.sample/ next to
>org.apache.cocoon.lucene.lucene/ ?
>
Don't get the "org.apache.cocoon.lucene.lucene/", do you mean 
"org.apache.cocoon.lucene/"?

>The former just being a non-osgi
>sitemap block,
>
As explained in my previous answer, sitemap blocks will also be OSGi blocks.

>the latter being the component Block that can be included
>and referenced in m2. See also my reply to "[RT] Flattening trunk".
>  
>
I'm not certain about exactly what "distinction" you refer to above. 
Blocks (bundles) will be able to expose: classes, resources, components 
and sitemap functionality. For some blocks it will make sense to expose 
most or all of these categories and for others just a single category.

For a block that exposes *reusable* sitemap functionality it might make 
sense to expose this together with components and possibly APIs. I would 
assume that hypothetical future Forrest, Lenya and Linotype blocks would 
do that. Samples are normaly *non-reusable* and therefore it is better 
to separate them. The reason for the core block to be a component (and 
API) block is mainly that it doesn't have any obvious reusable sitemap 
functionality to export.
 
/Daniel


Mime
View raw message