cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans>
Subject Re: [RT] Moving configurations to core
Date Sun, 25 Sep 2005 20:31:14 GMT
Daniel Fagerstrom wrote:
>> 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/"?
yes typo sorry.

>> 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.

The distinction I was referring to boils down to using separate my.block
and my.block.samples directories. You separated it for core, so I was
wondering if we should do this for all Blocks.

> 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.



View raw message