cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tcu...@dff.st
Subject Re: [PROPOSAL] make Cocoon modules alongside blocks (was Re: [RT] A deprecated module )
Date Wed, 04 Dec 2002 16:01:43 GMT
Quoting Nicola Ken Barozzi <nicolaken@apache.org>:

> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message