cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Blocks and packages
Date Sun, 28 May 2006 11:45:40 GMT
Daniel Fagerstrom wrote:
> 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.
Sorry to say this, but this statement is simply crap. I'm really annoyed
by those statements. Why can't you work on Cocoon3 anymore? I think you
are a little bit exaggerating here, aren't you? Starting an email with
such a paragraph is really not helping in starting a healthy discussion.
Is anybody else saying here that just because someone checked in
something which breaks building cocoon means "that we cannot work on
cocoon anymore?" I have rarely seen such statements in the past here and
I'm really wondering what your motivation for such statements is.

> 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).
I thought we discussed this and I think it was you who said that it's
possible to have several bundles export the same packages. But even if
that is not possible now, we have to distinguish between bundles and
(maven) modules I think. The current bootstrap module has one single
reason: the paranoid classloader. It contains all classes that have to
go into WEB-INF lib. Everything else can be loaded from the paranoid
class loader from any destination. So this module is just there two
create a separate jar(!) - not bundle. I'm not sure, but I think most of
this stuff is useless for OSGi anyway as OSGi will do the classloading;
Is it possible to have an OSGi bundle which exports classes of two jars?

> <SNIP/>
> 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.
Yes, this is a good choice, but as we also discussed we can't simply
rename the packages for existing code because of compatibility. So I see
this as a long term goal.

> 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). 
Whatever you think is best, just go ahead - these classes are all new
for 2.2 anyway so we can use any package. In addition if you think that
bootstrap is the wrong module name, go ahead and change it.

> 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 
> WildCardHelper.
Yes, if you think that it helps, move ClassUtils back to core. The only
solution for the WildCardHelper is to duplicate the code if it's rely
required to have distinct package names. The former version was in the
o.a.c.matching.helper package. We could put it back there.

I really think that these package name restrictions of OSGi bundles will
lead to problems in the long run for us. Just to stress the portal as an
example, I want to split the code base into several modules(!), one for
the portal core, one for the portlet integration, one for the wsrp4j
integration and so on. Now, all classes have the base package
o.a.c.portal, while the different modules use sub packages like
o.a.c.portal.pluto or o.a.c.portal.wsrp4j; I really hope that we don't
have to give up these package naming conventions just because of the
OSGi bundling. I currently don't know if each module will be an own
bundle or not and how this will work in OSGi; but I think that the ideal
solution for this would be that I don't have to worry about that and
just write my code. Everything else will then hopefully handled by the
framework I use.


Carsten Ziegeler - Open Source Group, S&N AG

View raw message