[PROPOSAL] Take two: modules -> environments + features ( was: make Cocoon modules alongside blocks)

[Nicola Ken Barozzi <ni...@apache.org>]

>>> 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 CocoonServlet.java and Main.java
[...]
>>>> 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.

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

   ./src/environments/cli/**
   ./src/environments/servlet/**
   ./src/environments/ant/**

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
--------------
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 
caching...

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?


                          -o-

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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [PROPOSAL] Take two: modules -> environments + features ( was: make Cocoon modules alongside blocks)

[Nicola Ken Barozzi <ni...@apache.org>]

Nicola Ken Barozzi wrote:
> 
> 
...
>  environments
...
>  features
...

I forgot this:

   deprecated

It should be a separate dir. In fact, it seemed quite strange that we 
would have a "deprecated module", and now it would be even wierder: 
"deprecated feature".

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org