Reinhard Poetz wrote:
In Amsterdam at the GT Daniel gave a presentation
(http://cocoongt.hippo12.castaserver.com/cocoongt/daniel-fagerstrom-blocks-2.pdf)
about Cocoon blocks and one of his slides contained a roadmap for Cocoon
blocks. This roadmap was discussed in the breaks and AFAICT is was
widely accepted. Of course this doesn't mean that this is community
consensus as not all have had the chance to comment on this yet.
So here is the roadmap and let's discuss it "officially" on the mailing
list:
- Cocoon 2.2 will not use OSGi but will support blocks as far as possible:
- blocks protocol (= sitemap blocks)
- a block gets its own component manager that contains all local
components
and gets the block component managers of all wired blocks as parent.
- we use M2 as build and deployment tool (needs some special M2 plug-ins
for the deployment part)
- blocks are distributed as binaries
- blocks are *not* spread over different directories during deployment
- a block can contain classes in [block]/BLOCK-INF/classes that are
added
to the context classloader
--> this means that everything, that real blocks promise, works
except the
shielding of Java classes.
- Cocoon 3.0 will use OSGi --> shielding classloader and hot plugablillity
Although Daniel has emphasized this many times I want to repeat it: We
don't need to branch trunk for this roadmap. OSGi development can be
done in parallel and we can avoid the unsatisfying situation of
maintaining two branches.
Of course future development can show that this or that is not possible
or should be done differently (who knows now, if OSGi will really make
it) but IMO it's nice to have a goal and something that we can
communicate to other projects that depend on Cocoon so that they have
enough time to adapt their design decisions.
I'm +1
One thing, though, remember to also have a LinkRewritingTransformer that
is block aware so that we can do
<style src="block:skin:/styles/main.css"/>
and this gets translated in the right URL (hopefully relative, so that
we don't have issues with webapp proxying, or, if absolute, we need a
way to configure where is the cocoon mountpoint as seen from the proxy side)
I'm currently doing
http://simile.mit.edu/repository/linotype/trunk/stylesheets/absolutize.xslt
with my latest linotype and I can't wait to get rid of all these hacks :-)
--
Stefano.
