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 CocoonServlet.java and Main.java
> 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
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
