cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Micro kernel based Cocoon
Date Sun, 22 May 2005 11:20:57 GMT
Carsten Ziegeler wrote:
> 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.

That is my number one priority. About everything I propose aims towards 
this, if it actually will help is of course another question ;)

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

IMO it will. AFAIU the plugin concept in Eclipse is considered straight 
forward for most people. The blocks will be very similar to plugins.

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

IMO it will be the other way around. And be sure that its not based on 
just "beeing cool". It solves very real and concrete problems.

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

Its not an exchange of Avalon with OSGi. In the firsts steps in the plan 
I propose OSGi is completely orthogonal to OSGi. It solves 
modularization, classloader and dependency concerns that our current 
container doesn't adress at all.

In a later step we might or might not want to use OSGi services that 
overlaps with Avalon ones. But that is a later question that we can base 
on the experiences we have gained at that time.

> But again, if I'm the only one with these feelings, I can simply shut up
> and watch the show :(

I think that everyone should raise their issues so that we don't misses 
any important consequences. So please continue to make your voice heard ;)

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

I propose to add some build tasks that add fields to the manifest files. 
  And to add some OSGi wrapper code outside the current Cocoon. There 
will, in the first steps, be no dependencies from the current Cocoon on 

IMO this is unrelated to and will not affect any 2.2 release schedules.

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

If you feel that it is feature complete you can release an alpha right 
away. Cleenup can be done afterwards. If you can author a list on what 
you think needs cleanup, it would help.


View raw message