[PROPOSAL] make Cocoon modules alongside blocks (was Re: [RT] A deprecatedmodule )

[Nicola Ken Barozzi]

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

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.

Below is part of the original thread.

Carsten Ziegeler wrote:

Nicola Ken Barozzi wrote:

Carsten Ziegeler wrote:

I still think that the current "blocks" we have in the cvs head are the
modules - and when we introduced them, I proposed to call them modules
first. Ok, but that's the past - let's be constructive.

Currently they are in fact packaged as "modules", ie as jars that need to be there at startup. In this I agree with you.

But IIUC there is no code there that cannot be in the future repackaged in a cob and be dynamically loaded. There are only Cocoon Components and Avalon Components.

True

Making a deprecated thing, would probably become a deprecated block for deprecated Cocoon components, and a deprecated module for Cocoon modules (ie all that can be taken out of Cocoon core but is not to go in COBs).

I'm fine with the name modules and this separation. But then we should
perhaps rename the modules.xml to something else.

the root module.xml?

Yupp :)

hehehe, that's the gump descriptor, some call it gump.xml, some projectname.xml, I called it module.xml because of CVS module.
hehehe it does create confusion. What would you prefer as a name?

project-info.xml ?

Good choice! +1 for project-info.xml

--
Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]