I hadn't thought of this before, but I suppose this means that end user
applications using Cocoon will need to be built with Maven 2?
Ralph
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.
WDOT?
