2008/9/3 Geir Magnusson Jr. <[EMAIL PROTECTED]> > > On Sep 3, 2008, at 9:14 AM, Richard S. Hall wrote: > > Geir Magnusson Jr. wrote: >> >>> >>> On Sep 3, 2008, at 12:10 AM, Sahoo wrote: >>> >>> >>>> 1. Package the interface in A or in some other bundle C. If you chose >>>> bundle C, then let A import that package. >>>> 2. Package the service impl in B. Let B import the interface. >>>> >>>> OR >>>> >>>> 1. Package the service interface and implementation as part of B. Export >>>> only the interface package from B. >>>> 2. Add a DynamicImport-Package for the service interface package in A's >>>> header. This would work as long as A does not refer to the interface before >>>> B is installed. >>>> >>> >>> This makes the most sense to me for some reason, although I don't have a >>> strong argument why - it just feels better to have the interface *not* in A, >>> and I'm to lazy to want to worry about a C ) >>> >> >> This is the main different between optional versus dynamic, dynamic will >> continually attempt to create a wire to the package at run-time. However, >> this is not intended as a general approach. It is really intended for >> SPI-like situations where you do not know the package. Although, it is >> reasonably safe to do this if you do know the precise package. It is a very >> bad thing to dynamically import "*". >> > > Got it. > > >> >> When you have public API and if you want to guarantee that your client >> dependencies resolve, you can include that API in your bundle then both >> import AND export it. Likewise in your service implementation, you can >> contain the public API and import AND export it. When the framework resolves >> dependencies, it will try to resolve the import first, rather than using the >> export, that way it will avoid creating new class spaces. Check out our OSGi >> FAQ for some discussion on this topic: >> >> http://cwiki.apache.org/FELIX/apache-felix-osgi-faq.html >> >> There is no single answer to this situation, it just depends. You have to >> decide what works best for you with respect to your modularity needs. >> > > Seems kind of yecchy to have to include the API (the interface of the > service) in the bundle that uses it. I assume I could just add a third > bundle to the mix, on that contains my service interfaces? and have both A > and B reference it ? >
yes, that would be the bundle C that Sahoo was talking about earlier it's a trade off - you can either package the API in the same bundle, which means one less bundle to manage - or you can push it into a separate API bundle, and avoid duplicating content some people prefer to include any required APIs, especially when they want others to take their bundle and drop it onto a framework without having to dig around for the various API bundles other people like fine-grained bundles, as it gives them more flexibility the benefit of OSGi is you can try out various approaches to slicing a project into bundles and your assembled application will (usually!) still work - and tools like BND make it easy to re-slice at any time... FYI, there was an interesting thread on the osgi-dev list in June titled "Put API/SPI/implementation into separate bundles?" which discussed various approaches [ https://mail.osgi.org/pipermail/osgi-dev/2008-June/thread.html ] geir -- Cheers, Stuart
