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 <[EMAIL PROTECTED]> 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
