John Morrison wrote:
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
[...]
Nope/Yup ;-)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?
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
