cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
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.


Great!

>                      --- 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 
> http://www.osgi.org/osgi_technology/download_specs.asp?section=2. 
> 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.
>
> WDYT?


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

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message