0

I am currently working to add OSGi modularity to a project for the purpose of plugins. The basic idea is that users can develop their own plugins that can be added at runtime to the main application to extend or modify its functions and/or capabilities.

For example, the main application uses Restlets to define an HTTP API for the application. The user may wish to create a plugin to add an endpoint with a specific function. Or they may wish to create a new entity that is stored in the database with a specific purpose.

I understand that this is not a 'true' OSGi modular application implementation and after some research I managed to quite easily add OSGi capability to the existing project with embedded Felix. Along with felix.fileinstall the application watches a deploy folder and automatically installs and starts the jar bundles that are dropped into the deploy folder (stops and uninstalls when removed).

So the basic idea is implemented and work great. What I'm struggling to understand is how I define and publish the main applications API (that can be implemented by any plugin bundles). On the flip side I don't understand how bundle developers can gain access to that API info?

In order for a bundle developer to be able to utilise the API they would need some sort of SDK?

tarka
  • 5,289
  • 10
  • 51
  • 75

1 Answers1

0

One approach would be to set the Constants.FRAMEWORK_BUNDLE_PARENT framework launch property to your application class loader and the Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA framework launch property to the list of packages that you want to expose to plugins. The plugins would then use Import-Package in their bundle manifest for your application's packages in the same way as any other package.

Brett Kail
  • 33,593
  • 2
  • 85
  • 90
  • This does 'bind' the two applications together at runtime so that the plugins can access the core application API that I want to expose. However, I still don't understand how this helps during development? You cannot write `import com.parent.some.package.Class;` in the plugin and expect the IDE import that class if its not a dependency. You cannot either make the core application a dependency of the plugin as it will then expose more that just the desired API. I feel like I should provide an SDK that the plugin developer uses as a dependency? – tarka Sep 12 '15 at 09:05
  • @tarka I don't know what problem you're trying to solve in the IDE. Are you trying to prevent people from accidentally depending on non-API classes that are part of your application JAR? Then sure, an API-only JAR for plugins to compile against (is what what you mean by "SDK"?) could work, or just document what plugin authors are supposed to use. They'll either follow the docs and their plugin will work or they'll use something they shouldn't and OSGi will block them at runtime. – Brett Kail Sep 12 '15 at 16:42
  • Currently the scenario is that there are 2 separate JAR; the core host application and the totally separate OSGi bundle. At runtime the OSGi bundle is registered with the host application and the host exposes the API methods to the bundle. However, When I develop the bundle it is not registered with the host. Its an independent set of classes. So how do you make the bundle aware of the host API in the IDE so I can `import` the host API classes to the bundle classes? – tarka Sep 12 '15 at 17:18
  • I don't understand how the IDE problem is related to the OSGi problem, so I would suggest opening a separate question. I guess the answer will depend on which IDE you're using? – Brett Kail Sep 13 '15 at 01:00
  • Sorry I am really not explaining myself well! Scenario... the host application is proprietary so you (bkail) cannot access it. However, I define in my documentation that the host will expose an API `com.example.host.api.SayHello`. How do you (bkail) develop a bundle that can import `com.example.host.api.SayHello` when you don't have access to the host application except at runtime? – tarka Sep 13 '15 at 17:50
  • Presumably you (tarka) would provide some JAR containing SayHello that I could put on my project's classpath. That JAR could either be a specially-crafted JAR containing just the API, or it could just be the full application JAR. – Brett Kail Sep 14 '15 at 03:15