On 25/03/2008, Tim Moloney <[EMAIL PROTECTED]> wrote: > > Stuart McCulloch wrote: > > On 25/03/2008, Tim Moloney <[EMAIL PROTECTED]> wrote: > > > >> I have created a simple bundle that uses org.apache.felix.log and > >> org.apache.felix.eventadmin. Although I build against > >> org.osgi.compendium (for the interface definitions), I can run without > >> it. I just started using org.apache.felix.wireadmin in my bundle and > it > >> requires compendium to be running in the framework. > >> > >> - Should org.osgi.compendium be running in the framework to run > >> org.apache.felix.wireadmin? > >> > > the wireadmin bundle needs the wireadmin service API > > which is provided by the compendium bundle - I guess > > it could embed this API for convenience (and then both > > import and export it, in case the compendium bundle is > > already loaded) but I don't think the spec mandates this > > Wouldn't it make sense that a bundle that implements a service, export > that interface? I think that org.apache.felix.log and > org.apache.felix.eventadmin both do this.
this isn't mandated by the spec - yes, it is convenient for bundles implementing a service to contain and export the API - but this also means more duplication, slightly larger bundles, and potentially makes it harder to swap bundles while the system is up and running for example, if I publish the API in one bundle and put the implementation in another then consumers will be wired to the API bundle. I can then swap various implementations in and out without disturbing the bundles wired to the API this also means it's easier to unload implementations as the implementation classloader won't be kept alive by the API references, because they're in a separate bundle... > so currently it needs the compendium bundle - or rather > > any bundle that exports the wireadmin service package > > I guess that I could always load the compendium bundle so that I have > the API. Unfortunately, the compendium requires javax.servlet so I'll > have to load that also even though I don't use it. true - although the next release of the felix compendium bundle will use DynamicImport-Package:* to avoid having to pull in the javax.servlet package if you don't need it. ( the 1.0.0 release omitted this setting by mistake ) > btw, you may find your bundle can run fine without the > > compendium bundle if it doesn't get round to invoking > > code that needs the API (or if it happens to embed it) Would it be a good idea for my bundle to include (as private packages) > any interfaces it uses? This way, my bundle won't have any failed > dependencies. I can then gracefully handle any missing services rather > than failing to load. if you do decide to include the APIs inside your bundle then (regardless of whether you export them) please make sure you import them, otherwise you will see class cast issues when your bundle is used on a system which includes the compendium bundle always import APIs even if you contain and/or export them personally, I prefer to keep APIs in a separate bundle as I find this more flexible - but if you want to keep bundles down to a minimum then embedding the API is fine, as long as you're careful with your imports and exports :) > I typically only add the bundles > > needed to compile against in the actual bundle pom > > (a lot of the time just core+compendium) > I understand this part. > > > and list the > > provisioned bundles separately with 'provided' scope > > in another deployment file/pom > > > I don't understand this. Can you elaborate? well, I do a lot of demos/practicals so I use scripts and archetypes to quickly create bundle projects - google "Pax-Construct" if you're interested the generated projects have a separate pom under a "provision" directory where I list the bundles that are to be deployed/provisioned along with the local compiled/wrapped bundles. the maven-pax-plugin scans the bundle poms and this provision pom to determine which bundles are to be deployed onto the framework - any optional dependencies are ignored and won't be provisioned it then creates a "deployment" pom that is passed onto Pax-Runner to do the actual deployment this means I can compile against one set of bundles (marked as optional in the bundle pom) and deploy against a different set (listed in the provision pom) I could even add maven profiles to the provision pom to support deploying against different sets of bundles - it's very flexible... -- Cheers, Stuart
