cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: [RT] Micro kernel based Cocoon
Date Sat, 21 May 2005 18:15:00 GMT
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)

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

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

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 build.properties contain a flag whether this or 
the stable version is built.

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 :-(

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------


Mime
View raw message