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
