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