cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject [PROPOSAL] make Cocoon modules alongside blocks (was Re: [RT] A deprecated module )
Date Wed, 04 Dec 2002 15:28:05 GMT
Now I'm a bit lost on the results of the RT deprecated thread 8-) so I'm 
making this into a proposal.


This proposal is to create a source section parallel to blocks, to hold 
Cocoon "parts", or "modules", that are not part of the Cocoon minimal 
core but need nevertheless to be included in the classpath and config 
files at startup.

They would look identical to the current "blocks", ie jars. The 
difference is that they will never be hot-pluggable as Cocoon 
Components, and are not part of the Block concept.
Thus, when proper .cob blocks will arrive, the /blocks will migrate to 
that packaging format, while these "modules" will not.

Possible candidates to be repackaged as modules:
  1 - deprecated classes that are not Cocoon Components
  2 - Environment implememtations
  3 - "frontends" like and
  4 - samples
  5 - module implementations
  6 - profiler

Many more can be moved, but these are the ones that ATM make more sense 
to me.

We also need a name for these "parts", currently I'm for "modules", but 
suggestions are welcome.
Also module.xml is confusing, since it means CVSmodule... 
project-info.xml is a proposal, any other or it's ok?


Below is part of the original thread.

Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>>Carsten Ziegeler wrote:
>>>I still think that the current "blocks" we have in the cvs head are the
>>>modules - and when we introduced them, I proposed to call them modules
>>>first. Ok, but that's the past - let's be constructive.
>>Currently they are in fact packaged as "modules", ie as jars that need 
>>to be there at startup. In this I agree with you.
>>But IIUC there is no code there that cannot be in the future repackaged 
>>in a cob and be dynamically loaded. There are only Cocoon Components and 
>>Avalon Components.
> True
>>Making a deprecated thing, would probably become a deprecated block for 
>>deprecated Cocoon components, and a deprecated module for Cocoon modules 
>>(ie all that can be taken out of Cocoon core but is not to go in COBs).
>>>I'm fine with the name modules and this separation. But then we should
>>>perhaps rename the modules.xml to something else.
>>the root module.xml?
> Yupp :)
>>hehehe, that's the gump descriptor, some call it gump.xml, some 
>>projectname.xml, I called it module.xml because of CVS module.
>>hehehe it does create confusion. What would you prefer as a name?
>>project-info.xml ?
> Good choice! +1 for project-info.xml 

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, email:

View raw message