felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Bundling interfaces and implementations
Date Wed, 06 Dec 2006 17:32:09 GMT
Aaron Siri wrote:
> 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?

I believe that a middle ground can be reached here...

-> richard
> -Aaron
> -----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
> 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

View raw message