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
