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. ok. Regards Jorg
