cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [osgi] Package structure
Date Tue, 07 Jun 2005 21:43:21 GMT
Daniel Fagerstrom wrote:

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


>                      --- 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
>   -------------
>   Export-Package:
> org.apache.cocoon.generation,org.apache.cocoon.transformation,...
>   Batik Bundle
>   ------------
>   Export-Package: 
> org.apache.cocoon.generation,org.apache.cocoon.transformation,...
> 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:
>   org.apache.cocoon.blockname.**

Yep. That's how it's done for Eclipse plugin. Each plugin has a name 
which is unique among all plugin and which is the root package for 
classes contained in the plugin.

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

Sounds good. A number of blocks already take this approach. Those that 
don't are AFAICS mostly the ones that existed before being moved to 
blocks (e.g. SVG).


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message