cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] A deprecated module
Date Wed, 04 Dec 2002 11:20:35 GMT

Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>>Carsten Ziegeler wrote:
>>>it just came across my mind to create a "deprecated" block/module
>>>which contains all deprecated classes and interfaces. This would
>>>clean our core but we would still have compatibility when the
>>>block is used.
>>>Does this make sense? What do you think?
>>I think that the idea is excellent, but I wouldn't make it a block.
>>Blocks will be pluggable components, ut what you envision may need the 
>>classes at startup.
>>I would propose that we mimic the blocks build system for a section that 
>>contains Cocoon "parts" that can be used on startup, but can be taken 
>>out of the core.
>>I sent a mail some time ago about this, to create "modules" alongside 
>>blocks, but then I married, didn't follow it, and didn't even see if it 
>>had arrived ;-)
>>In this way the core can be smaller still, and we can keep additional 
>>functionality that is not part of the blocks concept separate. This 
>>could also help in making Cocoon profiles for smaller devices or such.
>>We would still have to decide the name though, is "modules" ok? Dunno.
> Ah, now here we have the old modules vs. blocks discussion... :)


> 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.

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?

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 ?

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

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

View raw message