Quoting Nicola Ken Barozzi <[EMAIL PROTECTED]>:
> 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 CocoonServlet.java and Main.java
> 4 - samples
> 5 - module implementations
> 6 - profiler
Hm... this could really make it hard to have an overview of the codebase.
Consider you are looking for a specific class... It might be in module A
java/org/apache/cocoon/... or in module B java/org/...
For some classes it *might* not be obvious in which module to find them...
BTW: I bet people will getting cross-eyed having to deal with modules as well
as with blocks. ("What's the difference?" gonna be a candidate for the FAQ)
...so I am currently -0.25 :-/
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
