Carsten Ziegeler wrote:
<snip/>
I'm currently still missing the *big picture*. What are blocks, how does
Cocoon look like with them. Can I develop something without blocks? What
do I have to learn? And so on. This might be because I didn't have so
much time for Cocoon in the last weeks, don't know.
It would require quite a lot of work to give a fair overview of what we
have discussed about this in the last three or so years. You find some
info in http://wiki.apache.org/cocoon/Blocks. And for the relation to
OSGi I suggest that you reread my first post in this thread together
with some of the references.
I can give a short overview on how I currently view what Cocoon would
look like if we go the OSGi bundle way.
All current blocks, the core and libraries that are used by several
bundles are packaged as bundles. These are deployed in a OSGi kernel.
During development the Cocoon bundles can be deployed within the OSGi
kernel of Eclipse together with various Cocoon develpment plugins
(bundles). And during deployment the Cocoon bundles are deployed in a
standalone kernel that either is started from within an servlet or at
"top level" and contains a http server.
The OSGi kernel is like an OS kernel. It takes care about starting and
stoping bundles and to resolve dependencies between bundles and gives
them a parent classloader containing their dependencies.
The above means that we can get a much higher level of isolation beween
different parts of core and between blocks. As the bundles don't need to
expose all classes to everyone anymore. This is something that we
allready need quite badly IMO, and a must if we wish to make it possible
for external communities to develp Cocoon blocks.
Having this means that a user can download a minimal Cocoon disto with
some core bundles and a bundle (block) management utility. This can then
be used for download and deploy the rest of the bundles that the user need.
I also think that the current core should be splited in a number of
bundles. I would like to have a Cocoon core bundle that contains the
tree processor, the component manager and core interfaces. The Cocoon
core will define what Cocoon is. It will have an own release cycle like
an OS kernel. And the stable release should be rock stable. The servlet
and CLI environments should be own bundles. The flowscripts could be an
own bundle. Most of the components in current core could be transfered
to own bundles.
By breaking up todays monolitic core we are able to deprecate things
that we don't believe in anymore and move to an own bundles that still
will make the functionality available for those depending on it,
whithout making core bloated.
--- o0o ---
Above this we have the "sitemap aspect" of blocks. Its more at the
application level and doesn't have much to do with our current blocks.
It is more for creating reusable application frameworks. It will be
usefull for projects like Forrest, Lenya, Daisy, Linotype and probably
for Portal. It gives you a possiblity to create bundles that not only
exposes components and can contain own components, but also make sitemap
functionality available through the block protocol.
/Daniel
