cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Blocks and packages
Date Sun, 28 May 2006 21:17:56 GMT
Carsten Ziegeler skrev:
> 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.

I'm sorry if you felt attacked, I had no intension to attack you or 
anyone else. There was a problem that needed to be solved so that I 
could continue to work. Of course I could have solved it without asking 
at the list first. But as it involved changing packages on classes that 
might be part of our contract and reverting some of your recent changes 
I thought it was much better to ask on the list first so that we could 
find a solution that take all needs into account.

>> 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.

I hope I have not said that, in any case it is close to false (see the 
third paragraph in 
http://www.osgi.org/blog/2006/04/please-tell-us-what-you-want-from-osgi.html). 
There is some complicated workaround that can be used (see 
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg01004.html and the 
rest of that thread), but I think it adds other problems, so I think we 
should avoid split 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;

Might be, but o.a.c.classloader is needed in cocoon-core, so I cannot 
just ignore cocoon-bootstrap. From your explanation it makes sense to 
have it as a separate jar. For the time being it seems simplest to make 
it a separate bundle as well.

> Is it possible to have an OSGi bundle which exports classes of two jars?

A bundle is packaged as a jar, so it is not possible for two separate 
jars. A bundle can contain internal jars that are added to the bundle 
internal classpath. There is something called fragments in R4 where a 
fragment bundle can add optional things to another bundle. I haven't 
studied the details about them though.

>> <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.

We can go in this direction by tidying up the package structure and 
deprecate the split packages during 2.2 and remove them in 3.0.

>> 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.

Ok, I changed that.

>> 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.

The WildCardHelper is used outside the matchers, so it made sense to 
move it to util. I moved it back to util in core and kept a copy in 
bootstrap.

> I really think that these package name restrictions of OSGi bundles will
> lead to problems in the long run for us.

I'm certain that it will. Modularization is not for free, OTH having a 
huge monolith is even more expensive.

> 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.

As long as you don't want to contribute classes to a single package from 
several modules, it will be fine.

> I currently don't know if each module will be an own
> bundle or not and how this will work in OSGi;

I would suggest that each module produce a bundle, everything else seem 
complicated. The idea with modules IIRC is that they produce exactly one 
artifact.

> 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.

Sure, that would be nice ;) But I have never seen any framework that 
doesn't impose any restrictions whatsoever. And currently OSGi is the 
main modularization framework in Java and considering the development 
pace in the Eclipse community and elsewhere the restrictions seem to 
support development rather than hinder it.

/Daniel


Mime
View raw message