cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject [osgi] Package structure
Date Tue, 07 Jun 2005 20:36:13 GMT
I have started to experiment with OSGi, and this far it seem rather 
promising. I hope to be able to check in something in whiteboard rather 

                      --- o0o ---

A problem however is that our organization (or rather lack of 
organization) of packages in blocks, in some cases doesnt fit very well 
with how OSGi works.

Each OSGi bundle declare what packages it exports and imports. Then if 
several bundles exports the same package, the framework will choose the 
package from one of the bundles and feed it to all bundles that imports 
the package. Read the spec for geting the details There 
are, AFAIU, rather convincing reasons for solving it that way. 
Everything is handled at package level rather than at individual class 
level. This means that if:

   Cocoon Bundle

   Batik Bundle

and the Cocoon bundle is loaded first, 
org.apache.cocoon.generation.FragmentExtractorGenerator and 
org.apache.cocoon.transformation.FragmentExtractorTransformer will be 
available in any classloader in the system.

Bundle internal classes that not are exported can have the same name in 
several bundles, but exported ones must be unique.

                      --- o0o ---

I don't think this is special for OSGi, I would assume that any 
reasonable framework with classloader isolation, (if there happen to be 
any alternatives), has to do something like this.

Many blocks uses unique packagenames but not all.

So IMO we need a policy for package naming. Is there any "style guide" 
for package names for Eclipse plugins that we can adapt? Otherwise using 
something like:


seem rather reasonable. Alsp using impl as suffix on non exported 
packages seem like a good idea. There is of course no need to change 
blocks that allready uses unique package names even if they don't happen 
to follow the yet to be decided style guide.

A depredation strategy would be to move the classes to their new 
packages and then let the original classes be marked as deprecated and 
just extend the moved one. As Leszek did for 
org.apache.cocoon.generation.JXTemplateGenerator. Then it will work as 
before during the deprecation period and at the same time it can be used 
with the new package in a micro kernel environment.

                      --- o0o ---

I am completely aware about that this is rather inconvenient. But sooner 
or later I think we will have to create better order in our package 
naming anyway.



View raw message