felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <Peter.Kri...@aQute.biz>
Subject Re[2]: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Date Wed, 06 Dec 2006 16:05:42 GMT
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 choose,
RSH> since they will all work equally well on the OSGi framework. The main 
RSH> issues are that if you separate out interfaces, then you end up with a
RSH> bunch of small bundles needing to be deployed and you essentially have
RSH> 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 framework 
RSH> will correctly handle sharing among the different providers properly so
RSH> that they can interoperate (if possible). The main downside to this 
RSH> approach is that if you refresh the implementation it will also refresh
RSH> any dependent clients or other providers.

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