cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: [PROPOSAL] make Cocoon modules alongside blocks (was Re: [RT] A deprecated module )
Date Wed, 04 Dec 2002 15:46:26 GMT
On 04.Dec.2002 -- 04:28 PM, 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

why shouldn't deprecated components go into this (or another) thingy?
('phase_out' ?)

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

I was the culprit that caused the fuzz last time, I
believe. Personally, I think of org.apache.cocoon.components.modules
when "module" is used. Anyway, I will not stir this up again.
Thus I'm -0 on the name.

Apart from that, I'm +1

C h r i s t i a n       H a u l
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

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

View raw message