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.


--
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                       web(log): http://www.poetz.cc
--------------------------------------------------------------------

Reply via email to