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 09:37:56 GMT
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> Daniel Fagerstrom wrote:
>>> IMO, OSGi seem to be the best choice for kernel for Cocoon's block 
>>> architecture and there is (if I haven't missed something important) a 
>>> low risk, incremental and evolutionary way to get there.
>> Hmm, I'm currently not sure if we really need such an infrastructure for
>> our own blocks; it seems like a big burden and might make things more
>> complicated than they could be. Don't know.
>> I still have the problem that I can't see what real world problems will
>> be solved
> - 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)


I'm engaged in this because it IMO will give us a much needed 
*simplification* of using and develping Cocoon.

>> with this and what the drawbacks are.
> you're right, complexity is the price to pay. But maybe clearing 
> contracts makes things more comprehensible in the future ...

We have a lot of complexity today because of the lack of isolation 
mechanisms in Cocoon. It is monolithic and has so complicated internal 
contracts so that only a few people dare to touch it. Classloader 
isolation and declaration of dependencies and what is exposed, give us 
one mechanism for attacking this complexity.

>> Sure, it sounds cool...
>> Ok, anyways, I will not block any approach, I'm just trying to express
>> my current feelings about it. But I really thing whatever we do, this
>> should *not* be done in the current trunk. We should move 2.2 out the
>> door as soon as possible and target "real blocks" for a later release.
>> So, try out OSGi if you want, but please not in the trunk.

The plan I suggest makes it possible to start develop it *whithin* trunk 
wtithout affecting current Cocoon. I'm very strongly against any more 
branching. IMO they have mainly been harmfull for us, this far.

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

We can do it that way.


View raw message