cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Handing over Cocoon Bean code
Date Tue, 31 Dec 2002 14:35:20 GMT

John Morrison wrote:
>>From: Nicola Ken Barozzi []


>>I have already separated these on my hd in two different dirs in
>>  ./src/environments/cli/**
>>  ./src/environments/servlet/**
> should these be blocks/modules/whatever_the_current_name_is?

Nope/Yup ;-)

In some quite recent mails, I came to the conclusion that we didn't need 
"modules", because they were in fact different beasts we were putting 
together in a single place.

So I came to the conclusion we could do with

1) ./src/deprecated

done, but the code still depends on them for compilation, hence a build 
jack to copy them back before the build

2) ./src/environments

done on my hd. Basically the build is like the blocks one, but while 
blocks will become dynamically pluggable, and become cobs, these will 
remain basically jars and be needed at startup.

3) ./src/features

Everything that is not a an environment but can be separated from Cocoon 
and is needed at runtime. Currently I have yet to find what a "feature" 
can be, since most of cocoon is pluggable due to Avalon, and can thus be 
in a block. This concept is put on hold till a compelling use case arrives.

>>So that Cocoon core is not dependent on servlets, and we can for example
>>run a minimal "embedded" Cocoon without the servlet stuff.
> Would be nice.
>>Legacy package names confuse IMHO the correct conceptual and actual
>>layering of Cocoon.
> Don't know an answer to this.  I would like to see the code for
> the bean though (read the emails :)

Yup, I agree.

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

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

View raw message