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.I like the concept but I'm afraid of overloading 'module'.... it's wild, but what about
_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
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.
'organs'
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 module]
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
