cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [osgi] dependencies & classloading
Date Fri, 01 Jul 2005 10:04:29 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.
> 
> 
> 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.
> 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.
> 
I think we had a long time ago a discussion about dependencies wrt
versions. IMHO,
it is an absolut requirement to be able to specify the version a block
depends on. You can't rely on the general understanding that version
1.(x+1) is 100% compatible to 1.x.
For example, it might be that a specific bug fix has been added to lets
say 2.6.1 while the bug has been reintroduced to 2.6.2. So you need a
way to specify that you exactly want version 2.6.1.
I think we discussed to use some kind of wildcards to specify the
version number, like 2.* or something like that.
If OSGi does not directly support this, we should add it.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Mime
View raw message