cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: Roadmap for Cocoon Blocks
Date Tue, 11 Oct 2005 11:44:34 GMT
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?


Reinhard Poetz wrote:

> In Amsterdam at the GT Daniel gave a presentation 
> ( 
> 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.

View raw message