cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Blocks and packages
Date Sat, 27 May 2006 12:01:26 GMT
After the recent refactoring of Cocoon where part of cocoon-core is 
moved to the new cocoon-bootstrap, we have two packages: o.a.c.servlet 
and o.a.c.util, that are split into two blocks. This means that we 
cannot work on Cocoon3 anymore.

With OSGi, dependencies are at the package level. If several bundles 
(blocks) provide the same package the framework will chose the package 
from one bundle and ignore the rest of the implementations of the 
package (actually, several versions of the same package can be used at 
the same time but that is not relevant for the current issue).

This means that it doesn't work to have a package split so that some of 
the classes in the package is in one bundle and some other is in another 
bundle (in R4 there are mechanisms two handle split packages, but it is 
not recommended and increase the complexity considerably).

We need to find a solution for this and also decide what conventions we 
should have for package naming and what we use packages for. OSGi (and 
Java in general AFAIU) is based on the concept that a package contains a 
number of classes that works closely together to provide some well 
defined functionality. In Cocoon we sometimes use packages in this way, 
but also quite often based on some kind of similarity, e.g. 
o.a.c.transformation. The later use of packages, doesn't work well with 
modularization. I recommend you to read Peter Krien's blog about why 
packages are the right level of modularization:

We have discussed package conventions for blocks before and 
o.a.c.<blockname> as package prefix for a block seam to be a reasonable 
convention, that package name clashes between block communities.

For cocoon-bootstrap I would suggest that we keep o.a.c.classloader as 
is, as the whole package was moved from cocoon-core and as it doesn't 
have anything with bootstraping to do AFAICS. o.a.c.servlet can go to 
o.a.c.bootstrap.servlet (we could possibly keep and deprecate 
o.a.c.[BootstrapClassLoaderManager|ParanoidServlet] in 2.2 and just let 
them extend the moved classes in o.a.c.bootstrap.servlet). o.a.c.util is 
most complicated, ClassUtils could go back to cocoon-core as it isn't 
used in cocoon-bootstrap, it is less clear what we should do with the 



View raw message