cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [osgi] metadata
Date Mon, 04 Jul 2005 12:57:45 GMT
Niclas Hedhman wrote:

>On Monday 04 July 2005 17:25, Reinhard Poetz wrote:
>>I'm a bit confused about the relation between import/export package and
>>Require-Bundle. Does anybody know about this?
>Is this R4 or Eclipse? I can't find it in R3 spec.
>By the sound of it, "Require-Bundle X" means that the bundle will not be 
>started without the "X Bundle" being present. A kind of "Must Have" 
>dependency. And the import is the "normal" "Would Like To Have" dependency, 
>understood implicitly that the bundle will work without it (work being fairly 
>loose description).
I gave some links about this in my answer to Reinhard. It is a little 
bit more flexible with than you guess above, but not much. Although it 
might seem atractive to depend on whole bundles instead of on a bunch of 
packages it seem to lock the dependecy on a certain implementation.

Cf with:

"One very important difference between OSGi and Eclipse is on dependencies.
OSGi expresses dependencies on imported packages (name and version), but not
on which bundle actually exports them. In other words, in OSGi, any set of
bundles can replace another set of bundles as long as the Java packages they
export are the same (name and version). In Eclipse, dependencies are
expressed on plug-ins. So Eclipse bounds plug-ins explicit together,
providing no separation between a plug-in API and its implementation."

from an early discussion about using OSGi as base for Eclipse, 
that I cited in an earlier mail.

The Require-Bundle dependency has AFAICS no correspondance to the 
interface blocks that are part of the blocks design. OTH something close 
to the intended behaviour can be achieved by creating an interface 
bundle that put all of the its interfaces in one exported package.

So while declaring dependencies at the package level rather than the 
block level isn't exactly what is specified in the blocks design, it has 
as you can see above some advantages, and by using some coding 
conventions we can get the same behaviour.

                                     --- o0o ---

Niclas, are you getting up to speed with OSGi? Any thoughts about how to 
use modern component management together with OSGi?


View raw message