cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [PROPOSAL] make Cocoon modules alongside blocks (was Re: [RT] A deprecated module )
Date Wed, 04 Dec 2002 21:10:07 GMT
Nicola Ken Barozzi wrote:
> Now I'm a bit lost on the results of the RT deprecated thread 8-) so I'm 
> making this into a proposal.
> _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?
> Thanks.

I like the concept but I'm afraid of overloading 'module'.... it's wild, 
but what about


Just like Cocoon is a body and you take and remove organs that are not 
necessary for its life.

[note: from the list above, I think 'samples' should be a block, not a 

Stefano Mazzocchi                               <>

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

View raw message