[-] WEB-INF
     +--- [-] blocks
           +--- wiring.xml
           +----[-] 384938958499
           |     +----[-] COB-INF
           |     |     +--- block.xml
           |     +- (the contents of http://mycompany.com/webmail/1.3.43)
           +----[-] 947384127832
           |     +----[-] COB-INF
           |     |     +--- block.xml
           |     +- (the contents of http://yetanothercompany.com/skins/fancy/1.2.2)
           +----[-] 746394782637
           |     +----[-] COB-INF
           |     |     +--- block.xml
           |     +- (the contents of http://mycompany.com/skins/corporate/34.3.345)
           +----[-] 394781274834
                 +----[-] COB-INF
                 |     +--- block.xml
                 +- (the contents of http://mycompany.com/repositories/email/exchange/3.2.1

where

  • wiring.xml contains the block IDs (which also identifies their

location on disk) wiring, mounting and configurations.

  • block.xml contains the block metadata (which belong to the block and

cannot be changed at deployment time).

NOTE: if the location path of the block is relative, it is searched by starting from the cocoon war context. The block content is *always*
extracted from the archives and saves "as is" inside the folder.

NOTE (development time): in order to simplify block creation and development, it will be possible to explicity indicate the location of an already existing and extracted block implementation on disk. The block manager should also have autoreloading features (configurable, of course) that should reload the configurations, the wiring and the exposed components when they are changed.

NOTE: the block metadata is placed in /COB-INF/ to avoid potential collision with Avalon Blocks that store metadata in /BLOCK-INF/

  • No labels