1

I am learning OSGi framework. What i found that Bundles consists of .class files and manifest file. Now suppose I have two bundles A and B and bundle B depends on bundle A's service. So while compiling bundle B i have to keep Bundle A's service class in the classpath of bundle B or have to keep it(Bundle A's service) inside bundle B so that compiler can compile. Now if we are doing so then how modularity is achieved and how the two bundles are independent. Please help. Thanks

user1147070
  • 491
  • 7
  • 21

2 Answers2

6

Use interfaces!!

You have in interface I. Class A implements I and therefore depends on it, both at compile time and at runtime. Class B uses an instance of I, which it obtains as an OSGi Service. Therefore B depends on I at compile time and at runtime.

Therefore neither A nor B has direct knowledge of each other. Implementation code is hidden, only the interface is visible and shared. And that's how modularity is achieved.

Neil Bartlett
  • 23,743
  • 4
  • 44
  • 77
  • Thanks for the reply. But wanted to know whether i have to keep the interface I in my bundle B so that it can be compiled and we get the jar then – user1147070 Jul 11 '12 at 06:55
  • The recommendation is to keep interfaces in a separate bundle, which you can put on the classpath of A and B when compiling them. – Björn Pollex Jul 11 '12 at 06:57
  • @BjörnPollex Do you mean that when a module is developed, the service interface and the implementation should be put in separate bundle? So in general, every module consists of at least 2 bundles, one for the API and one for the different implementations? – manash Jul 12 '12 at 07:21
  • @BjörnPollex Why the separation should be done at the bundle level and not at the package level? I'm new with OSGi but I understand that dependencies are also handled at package-level (i.e. import-package). – manash Jul 12 '12 at 07:22
  • @MickaelMarrache: Having the API in a separate bundle makes it easier to deploy multiple/different implementations of it. While dependencies are handled at package-level, deployment is handled at bundle-level, and this policy makes you more flexible there. – Björn Pollex Jul 12 '12 at 07:26
  • Also: APIs and implementations evolve at different rates. APIs change very slowly because that is the *contract* between you and another developer or customer: any time you change an API you potentially break consumer or providers of that API. Whereas implementation code changes very rapidly; every little bug fix is a change, but it doesn't break the other modules. Therefore you want to decouple the lifecycle. – Neil Bartlett Jul 12 '12 at 10:40
  • @NeilBartlett Something I'm missing in your answer, how could it be that neither A nor B has direct knowledge of each other? Programming through interfaces is a well known best practice, but at some points, A or B has to know which implementation of I to use. How is the true independence kept as you mention in your answer? Generally, this question is raised when one wants to instantiates a class that is specific to an implementation. DI comes to partly solve the problem but how is it working with OSGi? – manash Jul 12 '12 at 12:46
  • @MickaelMarrache This is exactly the point of OSGi Services. It can be done with DI but this builds on top of the service registry. I.e. the provider (implementer) publishes its implementation to the registry. The consumer queries the registry and obtains that instance, without needing to know the implementation class. – Neil Bartlett Jul 12 '12 at 14:55
  • Though it is good practice to have the api separately available it is also best practice to include the API in the provider. In general the relation between provider because a provider does not have backward compatibility. – Peter Kriens Jul 10 '13 at 15:06
0

Manually doing dependency management is error prone. I suggest you use maven to manage the dependencies. In addition, maven-bundle-pluginIn could help you check import/export bundle at compile time; while maven-eclipse-plugin help you generate eclipse projects according to the dependency configuration in pom.

Cole
  • 179
  • 6