cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Date Mon, 05 Aug 2002 14:56:33 GMT

Vadim Gritsenko wrote:
>>From: Nicola Ken Barozzi []
>>Vadim Gritsenko wrote:
>>>>From: Andrew C. Oliver []
> ...
>>>>My objection
>>>>is this.  Before there is an agreement and set of documentation
>>>>explaining "WHAT goes WHERE" then this will be contentious.
>>>+1. Before we start branching CVS, let's define what goes where.
> "Cocoon
>>>Organization" thread was exactly about this.
>>The branch is a playground, where many can *see* the difference
> instead
>>of just trying to understand it.
>>If you prefer I can just write the things I will move, but it just
> seems
>>easier to me to move them and have all evaluate it.
> My main concern about Cocoon health is that it grows with features which
> are *not* integrated with each other. Examples are:
> 1. CInclude vs XInclude
> 2. ESQL vs SQLTransformer
> 3. xscript vs session context 
> 4. ProgrammingLanguage vs Interpreter
> etc.
> All these features should be better integrated with each other, should
> be built on common code and share that common code. The resulting shared
> code base among features will easy maintenance burden, reduce amount of
> code, and will give better integrated Cocoon, where features are work
> with each other seamlessly.
> If you to break up things into several packages, it will be much harder
> to do integration work (if possible at all).

Just put them in the same component package.

> Also, can you comment on Andrew's suggestion:

I'm doing it since months now, it's called Centipede.
We are moving right now with the help of Ant-dev to a new level with 
build imports, and it will be proposed to Cocoon ASAP.

> And Konstantin's:

We don't really need different editions, Cocoon core is not that big.
What we need is instead the possibility of using Cocoon in different 
environments, hence the Bean (embedded), CLI (standard) and 
servlet/Phoenix (enterprise.)

> And Berin's:

We need to sepate implementations where needed and group them when not, 
a simple rule of -all separate- or -using same libs- is not enough, 
since there will always be many shared dependencies.
We need a list of the impls and the proposed "components".

>>AFAIK there doesn't have to be a vote to branch, but there is to be a
>>vote to switch codebases or to switch back.
>>For now, I haven't heard compelling reasons not to.
> My other reason is: the more (playground) directories we create, the
> more messy MAIN becomes. And, one cannot work with HEAD, because you
> cannot commit to HEAD.

I said BRANCH, not subdirs.

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

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

View raw message