[RT] Moving configurations to core

[Daniel Fagerstrom <da...@nada.kth.se>]

While all blocks have its component and sitemap component configurations 
as part of them selves (under WEB-INF/xconf and 
WEB-INF/sitemap-additions), the configurations for core instead is part 
of webapp. WDYT about giving core the same structure as all other blocks:

core/
  Manifest.mf
  pom.xml
  WEB-INF/
  java/ (or maybe src/)

and move the core sample part of webapp to core-sample. Then the webapp 
could be really minimal and directly reulsable for users.

 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.

/Daniel

Re: [RT] Moving configurations to core

[Daniel Fagerstrom <da...@nada.kth.se>]

Jorg Heymans wrote:

>Daniel Fagerstrom wrote:
>  
>
...

>>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.
>
>  
>
Yes we decided, IIRC, to do that a while ago. Now we just wait for 
someone to feel like doing it ;)

/Daniel

Re: [RT] Moving configurations to core

[Jorg Heymans <jh...@domek.be>]

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

Re: [RT] Moving configurations to core

[Daniel Fagerstrom <da...@nada.kth.se>]

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

Re: [RT] Moving configurations to core

[Jorg Heymans <jh...@domek.be>]

Daniel Fagerstrom wrote:
> While all blocks have its component and sitemap component configurations
> as part of them selves (under WEB-INF/xconf and
> WEB-INF/sitemap-additions), the configurations for core instead is part
> of webapp. WDYT about giving core the same structure as all other blocks:
> 
> core/
>  Manifest.mf
>  pom.xml
>  WEB-INF/
>  java/ (or maybe src/)

+1 , core is a block like all the others so why should it have a
different structure.

> and move the core sample part of webapp to core-sample. Then the webapp
> could be really minimal and directly reulsable for users.

+1

> 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/ ? The former just being a non-osgi
sitemap block, the latter being the component Block that can be included
and referenced in m2. See also my reply to "[RT] Flattening trunk".


Regards
Jorg