cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Directory structure of blocks
Date Tue, 12 Apr 2005 14:46:35 GMT
Pier Fumagalli wrote:
> On 11 Apr 2005, at 15:50, Reinhard Poetz wrote:
> 
>> Daniel Fagerstrom wrote:
>>
>>> Ok, I had some remembrance that we had decided to have a particular 
>>> directory structure on the COBs, but I couldn't find any 
>>> documentation on that, do you have any link or example?
>>
>>
>> no. But AFAIK there aren't many rules. Those that I know of are:
>>
>> Blocks have a block.xml descriptor and a COB-INF directory, that can 
>> contain a directory "classes" and "lib".
>> The block's root sitemap (if there exists any) is defined by the 
>> block.xml.
>>
>> I don't know why we named it "COB-INF" but there was (still is?) a 
>> good reason for this because I remember some long discussion. Apart 
>> from this I'm not sure where to put "block.xml". In analogy to WAR 
>> files it should be "COB-INF/block.xml".
>>
>> If the reasons for COB-INF vanished in the meantime, I propose 
>> following directory structure:
>>
>> --------------------------------------------------------------
>> [cocoon block] [DIR]
>>  |
>>  +-- BLOCK-INF [DIR]
>>       +-- block.xml
>>       +-- classes [DIR]
>>       +-- lib [DIR]
>> --------------------------------------------------------------
>>
>> WDYT?
> 
> 
> Again, to sound stupid, but why in the world a cocoon block would 
> contain classes and libraries? 

A block defines both services (thru its sitemap) and components (thru 
the classloader).

Presence of either is optional. If a block has only classes and 
libraries (or files in the class paths), it only works as a component 
provider.

If it has only a sitemap, it will require components from another block.

If it has both, it can expose services that use its own components and 
expose these components to the outside.

The 'components' to expose will be declared in the block descriptor, 
this allows us to avoid 'public' classes of the libraries shipped with 
the block to be misconsidered as components.

> Those should be external "components" 
> _required_ by the block, right???

see above: blocks brings components with them.

Also note that an 'interface' block is very likely to contain the 
component interfaces (and the remaining classes that these interfaces 
need to function).

So, for the sitemap, the block interface is just a URI, but for the 
component part, the block interface *contains* the interfaces.

this will require some more complex build systems as even compile time 
will require discovery and installation of components (this is the same 
problem that Merlin had and solved with Magic).

-- 
Stefano.


Mime
View raw message