cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject [PROPOSAL] Take two: modules -> environments + features ( was: make Cocoon modules alongside blocks)
Date Thu, 12 Dec 2002 23:55:39 GMT
>>> Nicola Ken Barozzi wrote:
 >>>> 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.
>>>>Possible candidates to be repackaged as modules:
>>>> 1 - deprecated classes that are not Cocoon Components
>>>> 2 - Environment implememtations
>>>> 3 - "frontends" like and
>>>> 5 - module implementations
>>>> 6 - profiler

So here is my second take at the proposal. It seems that it's not a bad 
idea but we couldn't find a name for them. I felt a bit uncomfortable 
seeing that we couldn't name it, and usually it means that it's mixing 
concerns or too generic. Actually it seems that it's both.

This new proposal keeps the same idea of creating Cocoon "parts" that 
should be present at startup, but differentiates between the two, by 
making environments and features.

The Cocoon environments are in fact composed by o.a.c.environment.* 
implmentations and other classes, transformers and 
serializers in the CLI and the servlet package for servlets.
So we would have:


these can depend on one another, but not with a circular dependency. For 
example the ant env would depend on the CLI one.

This takes care of points 2,3 in the initial list that is cited above.

Features are non-compulsory parts of Cocoon that add... err... features 
to Cocoon.

These would be the profiler stuff for example or eventually part of the 

Actually, looking at the code better, it seems that all these "features" 
can be put in blocks, since they will be able to add Avalon components 
to Cocoon.

What do you guys think?


As for the Cocoon Components that do not depend on non-JDK jars, I would 
make a single block of each of them, and leave in the core only the 
default ones we are using now, like the file generator, xslt ransformer, 
xml serializer and the-matcher-that's-so-standard-I-don't-remember-its-name.

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

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

View raw message