cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <>
Subject Re: [Proposal] Cocoon Organization (Cocoon plugins)
Date Mon, 05 Aug 2002 10:05:55 GMT
On Monday 05 August 2002 09:41, Carsten Ziegeler wrote:
>. . .
> we should try to build a minimal Cocoon or core Cocoon if you
> prefer and put everything else into additional modules (read: not blocks).
> By modules I simply mean different directories in the CVS in order to
> optionally build them. 
>. . .

It would be great if these modules could be pluggable at runtime, simply by 
copying the required jars in the right places. Users won't like having to 
recompile Cocoon just to activate different options IMHO.

I don't know Cocoon internals or Avalon in much detail, but maybe the 
following scenario could be implemented simply and help users locate and add 
the required functionality when they need it:

1) create an XML map of modules, classnames and URLs that is distributed with 
Cocoon, example: 


2) when a Component is requested from the Sitemap and is not available, a 
custom ClassLoader (or a catch of the ClassNotFoundException) uses the 
above map to let users know how to activate it, something like:

The "xslt-xalan" plugin (requested by blablabla...) is not present in your 
Cocoon configuration. To activate it, download file 
"cocoon-xalan-plugin.2.0.3.jar" from 
"", copy this jar to the 
WEB-INF/lib subdirectory of your Cocoon installation and restart Cocoon

I don't know how well this fits your plans, but it might help distributing a 
minimal Cooon while making it easy for users to install what they need. 

Just my 2 cents.
 Bertrand Delacrétaz (,

 buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
 disclaimer: eternity is very long. mostly towards the end. get ready.

To unsubscribe, e-mail:
For additional commands, email:

View raw message