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)
Exactly!
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 build.properties contain a flag whether this or the
stable version is built.
We can do it that way.
/Daniel
