Shouldn't we make these decisions on this list in the public? Not every committer was at the GT and took part in the discussions.
Carsten Reinhard Poetz wrote: > Niclas Hedhman wrote: > >>On Sunday 09 October 2005 01:43, Reinhard Poetz wrote: >> >> >>>I'm working on the classloader >>>part so that a block can come with its own classes. >> >> >>Curious to know what this is... or if it is a matter of lack of understanding >>of the OSGi classloader. >> >>Is there any additional classloading needs that can't be satisfied with the >>OSGi classloader mechanism?? Would indeed be interesting to know for the >>Felix development as well. > > > At the GT we had some kind of agreement, at least after Daniels presentation > on > blocks, that we go for a two-step roadmap to get 'real' blocks*: > > - 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 *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 > > So the answer to your question: We need this classloading only to load > classes > from within 2.2 blocks. 3.0 will make this 2.2 classloading stuff obsolete > (hehe, my favorite word these days). > -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
