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 build.properties 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
OSGi.
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.
/Daniel
