cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] Micro kernel based Cocoon
Date Sun, 22 May 2005 09:42:50 GMT
Reinhard Poetz wrote:
> - breaking up the monolitic Cocoon
> - getting over the Java jar hell
> - making development of Cocoon extensions outside of the
>    Cocoon project much easier (why there are hardly any Cocoon based
>    projects out, except Daisy, Lenya, Forrest and two or three others)
> - ever tried to run your own project and let's say Forrest
>    and maybe Lenya in one webapp application? Maybe possible but
>    I wouldn't want to manage this configuration (and good luck
>    with the next upgrade of one of them)
Ok, ok, I totally agree that we have to work on these points, no
question. For most of the points above we could provide an improved
build system, e.g. use Maven, and use the new functionalities we already
have in 2.2 and that's it. But that's not my point.

Cocoon has a very high learning curve, so we have to flatten this
learning curve. Users never really understood Avalon; but interestingly
everyone understands Spring - which is the same concepts of Avalon but
done differently (I know, I simplify here a little bit, please, all
Spring lovers forgive me for now!).
Adding a "complex" block system on top of Cocoon doesn't make things
easier. I have the fear that everything gets more complex and
complicated and instead of flattening the learning curve, we increase it
 - and that's just because of beeing "cool". - Don't get me wrong, I
don't know if this will be the case, it just my feeling right now.

During the GT last year we started a different route: flattening the
learning curve by separating the core container (avalon based) from the
things users should use. So in fact we encourage people to use something
else with 2.2, like Spring or Hivemind or whatever. So the users don't
have to learn Avalon anymore - again, a simplified view, but that's
possible with 2.2 today.
If we can make the block system - whatever it is - totally transparent
in the same way, and users don't need to know about, great - but if we
now "exchange" Avalon with let's say OSGi then this is in my view a big
But again, if I'm the only one with these feelings, I can simply shut up
and watch the show :(

> Why can't this be done in trunk as long as the old "monolitic" approach still 
> works? AFAIU there will only be another Cocoon servlet that initializes the OSGi 
> layer. If we come to the point that we have to introduce incompatibilites we can 
> still decide to move out the OSGi version into its own branch. But I'm sure we 
> will do our best to avoid any backward incompatibilites. IMHO development should 
> happen in /trunk/src/osgi and contain a flag whether this or 
> the stable version is built.
If we now start with trunk, we will never get 2.2 out *without* this
blocks concept working and that would delay everything imho.

> And AFAIU it's out of discussion that the OSGi layer will be part of Cocoon 2.2 
> - although it would be helpful to define what Cocoon 2.2 will be in order to get 
> it out - in the past all my efforts to reach a common understanding were not 
> very successful :-(
You're not the only one. We have the hackathon at the ApacheCon or we
can now start a thread about this topic and see (again) what other
people think.
In my opinion, 2.2 is more or less feature complete; there are *many*
things to cleanup and I'm currently playing with adding administration
and monitoring.


Carsten Ziegeler - Open Source Group, S&N AG

View raw message