cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [osgi] dependencies & classloading
Date Fri, 01 Jul 2005 10:38:13 GMT
Reinhard Poetz wrote:

> Yesterday I had some time to look deeper into Knopflerfish and the 
> OSGi spec.
> This has led to a question about dependencies that I want to share and 
> discuss
> with others.
> The most important reason why we are thinking about placing Cocoon on top
> of OSGi is it's feature of a "shielding classloader". Each bundle 
> (block) can
> import and export packages:
> Bundle-Name:bundle_C
> Bundle-Version:1.0.0
> Export-Package:com.myCompany.bundleC.blah
> Bundle-Name:bundle_C
> Bundle-Version:2.0.0
> Export-Package:com.myCompany.bundleC.blah
> Bundle-Name:bundle_A
> Require-Bundle:bundle_C
> Import-Package:com.myCompany.bundleC.blah
> Bundle-Name:bundle_B
> Require-Bundle:bundle_D
> Import-Package:com.myCompany.bundleC.blah
> My question now: How do I specify that bundle_A requires bundle_C, 
> version 1.0.0
> and bundle_B requires bundle_C, version 2.0.0? Is it possible (and 
> needed) at all?
> The OSGi spec recommends that bundles, or more exactly, the exported 
> interfaces
> and classes, should be backwards compatible. A simple "workaround" (or 
> solution)
> could be that a new incompatible version of a bundle has to get a new 
> namespace and that we don't export any packages of external libraries 
> and recommend block (bundle) developers to not do it either.

That is one possibility.

> For those who're asking for a usecase: Imagine that bundle_C is the 
> forms block
> and you want to deploy custom application A using version 1.0.0 of the 
> forms
> block and custom application B using version 2.0.0 of it which is 
> _incompatible_
> to 1.0.0.

OSGi R4 is extended with version ranges, so you can write:

Require-Bundle:bundle_C; bundle-version="[1.0.0,2.0.0)"

Require-Bundle:bundle_D; bundle-version=2.0.0

for Eclipse and
for more detailed documentation.

Here is a Eclipse bugzilla entry about the unsatifying state of the 
documentation, with some documentation links:

And here is an interesting comparison between, among other things, the 
package based export system in OSGi and the plugin based system in Eclipse:

> Another usecase: We could bundle frequently used libraries so that 
> they don't have to be added as local (shielded) libraries at every 
> block that needs them.

We should definitively do that.


View raw message