felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Siri" <Aaron.S...@efi.com>
Subject RE: Re[2]: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Date Wed, 06 Dec 2006 16:54:32 GMT
I actually don't mind import-package vs. require-bundle and reading the spec
I have to agree with you that import-package is the recommendation.

My issue is more of a packaging issue and how the plugin interprets the maven
environment.  The bundle plugin, unless I'm mistaken, rips classes out of
dependency, non-bundle jars and puts the classes into the local bundle rather
than just embedding the .jar as a .jar and putting it on the classpath.  It
ignores the maven dependencies for packaging purposes and forces the user to
manually figure out which packages are needed and specify them via

What if we did away with <Private-Package> (or detect a special value) and
just assume that all maven jar dependencies are required by the bundle
packages with packaging of the jars honoring the dependency definitions (i.e.
compile, provided, etc.)?  The classpath is added to the manifest.  You can
Export-Package/Import-Package as done today.  Could this work?

I'm starting to think that the older osgi-plugin was a better fit with the
maven model and that bnd isn't very mavenisable or doesn't translate to maven
well.  But maybe a happy median can be achieved?


-----Original Message-----
From: Peter Kriens [mailto:Peter.Kriens@aQute.biz] 
Sent: Wednesday, December 06, 2006 11:06 AM
To: Richard S. Hall
Cc: felix-dev@incubator.apache.org
Subject: Re[2]: Bundling interfaces and implementations (was: Bundle plugin:
Importing packages from non-bundles)

I completely concur with Richard. Import-Package is for me the way to go and
is even officially preferred by the OSGi Alliance (look at the disadvantages
of using Require-Bundle in the spec, and also in my blogs). One reason I like
Felix is this fanatic focus on decoupling.

The bnd plugin is targeted at making bundles directly from the classpath that
use Import-Package to minimize coupling between bundles. Packaging the spec
interfaces with the implementation is not only very easy with bnd, I also
think that is the right way to go.
Last week I worked on a demo and Felix jetty was the only bundle that ran
directly out of the box from OBR because it contained all its interfaces;
really nice in my opinion.

However, this model is very different from the maven policy of transitive
dependencies on artifacts.

Starting to support Require-Bundle in bnd is therefore counter to its
original goal. If you really think you need Require-Bundle, maybe this plugin
is not the way to go then. I am afraid that if I add all these features to
the plugin it becomes complex and bloated and overriding its original goal.

Maybe we need multiple plugins ...

Kind regards,

     Peter Kriens

RSH> On Dec 5, 2006, at 6:00 PM, Steven E. Harris wrote:

>> Richard S. Hall <heavy@ungoverned.org> writes:
>>> The spec used to recommend packaging a bundle with its 
>>> interfaces...I am not sure if it still does or not, but it is 
>>> definitely not anti-OSGi.
>> Today I've been wondering about this too. In many cases, I wish to 
>> define some service interface for clients to use, then write at least 
>> one implementation of the service interface. Clients will rely on the 
>> interfaces, but should have no knowledge of the implementation(s). 
>> What's the right way to package this in OSGi?
>> If I put the interfaces in the same bundle as the implementation, the 
>> two have to be in different packages to maintain the intended privacy 
>> of the implementation. Alternately, I can place the interfaces in a 
>> bundle, and have both the clients and the implementation bundle rely 
>> on that interface-only bundle. This is based on the assumption that a 
>> given class or interface should only wind up in one bundle. Also, the 
>> latter separated approach seems more favorable to there being 
>> multiple implementations of a single interface, as it wouldn't make 
>> sense to put the interfaces in the first implementation's bundle and 
>> have all other implementations rely on the first.
>> Since Felix is written largely as an implementation of a separate set 
>> of OSGi interfaces, it's more obvious how it splits the two domains. 
>> For an application or system that's more self-contained, though, it's 
>> harder to figure out a discipline for separating interfaces and 
>> implementations.

RSH> Overall, it doesn't really make a difference which approach you 
RSH> choose, since they will all work equally well on the OSGi 
RSH> framework. The main issues are that if you separate out interfaces, 
RSH> then you end up with a bunch of small bundles needing to be 
RSH> deployed and you essentially have no self-contained bundles.

RSH> If you package service interfaces with all of your service 
RSH> implementations (and both import and export them), then the 
RSH> framework will correctly handle sharing among the different 
RSH> providers properly so that they can interoperate (if possible). The 
RSH> main downside to this approach is that if you refresh the 
RSH> implementation it will also refresh any dependent clients or other

RSH> If you expect to only have one service provider at a time, then it 
RSH> might make sense to package the service interfaces with the service 
RSH> impl. If you expect to have multiple providers of the same service, 
RSH> then maybe it makes sense to package the service interfaces separately.

RSH> Unfortunately, there is no single rule.

->> richard

Peter Kriens                              Tel +33467542167
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599

View raw message