Re: New "module" terminology: WAS: Extending the build system for modules

["Andrew C. Oliver" <ac...@apache.org>]

Ken...  I love you man and I trust your judgement...  Just do me this 
favor...whatever you do...make it easy for my little mind to install and 
configure....pretty please..  And Wiki the hell out of it.

Thanks,

-Andy

Nicola Ken Barozzi wrote:
> 
> Conal Tuohy wrote:
> 
>> I realise that "blocks" are still vapour-ware, whereas "optional modules"
>> are at least imminent vapour-ware ;-) 
> 
> 
> ;-)
> 
>> but I'm still not entirely clear on
>> how the relationship between these "optional build modules" and the 
>> planned
>> "blocks" is supposed to develop. Can someone comment on how they see 
>> these 2
>> related concepts developing?
>>
>> It seemed to me that the CONTENT of each one of these things (i.e. the
>> components, sitemaps, scripts, docs, etc within a module, or block) 
>> would be
>> essentially the same, i.e. they should have the same granularity. This is
>> what I meant by "essentially the same", NOT that they use the same
>> mechanism, because obviously they are different. Is this right?
>>
>> When pluggable "blocks" are finally developed, will they be able to 
>> entirely
>> replace the mechanism for optional modules? Or will there be some 
>> optional
>> modules which will never become blocks? Is the optional build going to 
>> be a
>> temporary measure before blocks arrive? Or is it a step towards a 
>> component
>> architecture of blocks? i.e. a block = a module + some metadata? This is
>> what I'm still unclear about.
> 
> 
> I'm too ;-)
> 
> Ok, since I am the one going to make the change to the CVS, and since 
> with lazy consensus Carsten's who-committs-chooses-the-name, I therefore 
> hint that I might commit the change in a directory called "blocks".
> 
> Why?
> 
> Simple.
> A "module" will soon be a directory that contains
>  1) Avalon component(s)
>  2) Cocoon component(s)
>  3) resources
>  4) examples
>  5) configuration info
> 
> Example of a jsp module
> 
>  1) org.apache.cocoon.components.jsp.*
>  2) org.apache.cocoon.generation.JspGenerator
>  3) -
>  4) jsp samples
>  6) jsp.xconf
> 
> Example of a jsp.cob
> 
>  1) org.apache.cocoon.components.jsp.*
>  2) org.apache.cocoon.generation.JspGenerator
>  3) -
>  4) jsp samples
>  6) jsp.xconf
>  7) cocoon.xcob (cob descriptor)
> 
> As you see, the only difference is the existence of a descriptor and of 
> a mechanism for Cocoon to plugin the cob automagically, instead of 
> during the build.
> 
> So I see this as a first step to blocks.
> Once they are refactored in their directory it will be easier to make 
> the blocks work.
> 





---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org