If you haven't already taken a look at equinox you should. Eclipse is a good example of an app built atop OSGi from which to learn. If equinox is a bad word around here then I apologize.
Anyways, it already has the concept of plugins, extension points, etc built atop OSGi using xml descriptors. You can use it all without any of the eclipse UI/app framework. Just download the equinox SDK and you'll have almost everything you'll need. We are using it for a web-based application where we and third parties can plug in functionality. BTW, is the equinox/felix relationship friendly? -Aaron -----Original Message----- From: Steven E. Harris [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 05, 2006 6:34 PM To: felix-dev@incubator.apache.org Subject: Re: Bundling interfaces and implementations Richard S. Hall <[EMAIL PROTECTED]> writes: > The main issues are that if you separate out interfaces, then you end > up with a bunch of small bundles needing to be deployed and you > essentially have no self-contained bundles. Right, that's what I'm seeing emerge. For example, I have one bundle right now that has one class in it. The motivating scenario for my application is this: The application has a couple of "plugin types" (defined as interfaces) for which it expects to download and install lots of plugins, each of which will be an OSGi bundle. Perhaps this is analogous to a servlet container; there's one servlet API set, and lots of servlets that will come along and implement it. Obviously the application itself needs access to these interfaces, as do the plugins. The interfaces have no obvious home. If the plugins could be developed by third parties, we'd have to make the interface class files available in some way, regardless of what bundle they eventually wind up in. Normally we have these decisions to make about how to organize source in a tree, how to package it for distribution or deployment, and now with bundles we have yet another dimension to consider. > If you expect to have multiple providers of the same service, then > maybe it makes sense to package the service interfaces separately. That sounds more like my situation. > Unfortunately, there is no single rule. Even so, we need more example applications built atop OSGi from which to learn. -- Steven E. Harris
