cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Date Mon, 05 Aug 2002 14:33:26 GMT
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> 
> Vadim Gritsenko wrote:
> >>From: Andrew C. Oliver [mailto:acoliver@apache.org]
...
> >>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.
> 
> Why?
> 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).


Also, can you comment on Andrew's suggestion:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102814208304842&w=2

And Konstantin's:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102814539808547&w=2

And Berin's:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102814063603019&w=2


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


Vadim


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


Mime
View raw message