We Keep Coding

Defining and exposing host API with embedded OSGi

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?

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.

What is a good way to structure a library which should work in OSGI- and non-OSGI environments?

I am writing an application which runs in an OSGI environment.
Now I want to extract some code and put it in separate bundle/jar file to reuse it also in other applications (both, OSGI or non-OSGI).
My goal is to remove any dependencies to the OSGI environment classes, because it should also run in other apps which do not have all the jars of the various OSGI frameworks (e.g. Equinox). But at the same time I would like to register an OSGI Service in the OSGI environment if the Application is an OSGI app.
I have already separated the code and the only remaining piece of OSGI-dependent code is currently my Activator class which registers some class as an OSGI Service:
context.registerService(MyServiceInterface.class.getName(), new MyServiceImpl(), new Hashtable());
To remove the dependency, I think about the following:
I remove the Activator and OSGI dependencies from my bundle1
I create another bundle2 where I move the Activator
In the end I have my bundle1.jar which only has a Manifest.mf file to make it OSGI-ready, but there is no code anymore depending on OSGI framework classes.
I have another bundle which only belongs to my current application which imports bundle1.jar and has the only purpose of registering the MyService.class on the OSGI container using an activator.
Is this approach ok or are there any other best practices?
Is registering a service in the OSGI environment good practice or is this something which always the host application should be responsible for?

Why not just leave the activator class in your bundle. When run in a non-OSGi environment, the activator class will not be called. When run in an OSGi environment, it will. Isolating you OSGi dependencies to the activator is a fine strategy.

In most cases you can publish your service without Activator. Take a look at OSGI Comunity Wiki and Equinox example.

Another approach is to use blueprint. At least in simple cases it allows to have no dependencies to OSGi at all. For real world cases you typically need at least some OSGi APIs but it is no problem to leave them simply inactive in the non OSGi case.
You may also want to try PojoSR. It allows to use Activators and OSGi Services outside OSGi. We started to use this in Apache Camel to test OSGi code.

Using Spring-DM would help remove code dependency to OSGi. Your bundle wouldn't need an activator and the service can be exported from the spring-dm config xml. However, this does add a lot more runtime dependencies, but no compile dependencies are needed.

Efficient OSGi development workflow

I work on a product composed of many bundles running as features on top of karaf. Typically our developers work on one bundle at a time. Our normal development goes something like: code, compile, copy bundle to deploy folder, test. We've also found that hotdeploy just refuses to override certain bundles that are installed as features without a server restart or a feature uninstall/reinstall, so sometimes the cycle is longer.
My question is: does anyone in the community have a better way? The way we do things works, but I feel like it's pretty slow and inefficient and I'm betting someone has come up with something better!
EDIT: I realize that I was pretty unclear in my question... We are using Equinox underneath Karaf. We also use Eclipse and Maven, although I don't know that using Maven is relevant.

Sounds like you want the dev:watch command. From the documentation:
The watch command can be used to help at developement time. It allows you to configure a set of URLs that will be monitored. All bundles location matching the given URL will be
automatically updated. This avoids the need for manually updating the bundles or even copying the bundle to the system folder if needed. Note that only maven based urls and maven snapshots will actually be updated automatically, so if you run
dev:watch *
It will actually monitor all bundles that have a location matching mvn:* that have '-SNAPSHOT' in their url.
Doing "dev:watch --help" from the Karaf shell will list its available flags and args.
Something similar is the PAX plugin
Either of these will work quite nicely if you've got the m2 maven plugin for Eclipse.
UPDATED: In my company we strive to be as TDD as possible, therefore a lot a development is done without explicitly starting Karaf. In the normal mix of unit tests we're also using Pax Exam, which is largely fantastic even when run from within Eclipse =)
This helps ensure we're not too tided to any Karaf specifics as it runs with Equinox/Felix/Concierge (so I mock out various Karaf specifics we depend on like JAAS authentication). Along with many other cool tools/functionality, it's capable of provisioning Karaf features and using TinyBundles you can even create bundles on the fly (again useful for mocking/stubbing).
Pax Exam hooks into the JUnit framework by providing a JUnit #Runner, the latest version (2) is much faster and has DSL based API, so the tests are quite concise and readable.
Using Pax Exam gives us good test coverage and short development times. Where tests are less practical or we're hunting bugs that don't surface in tests, the dev:watch command is invaluable.
In summary; IMO you should definitely drive your developments with tests (Pax Exam will slot into your existing build nicely and once you get used to it you'll find development quicker). You can start using the dev:watch command immediately, it will certainly speed up your current situation.
UPDATE 2: In answering another question I've added a maven example Pax-Exam testing a ComponentFactory. Test Driven Development is arguably the most efficient workflow available to developers today. link to question: osgi: Using ServiceFactories? and link to sourcecode: http://dl.dropbox.com/u/2465717/net.earcam.example.servicecomponent_2011-08-16_15-52.tgz

I've had excellent results using Equinox in Eclipse - even hot code replace works properly. granted, the target platform is small and we have only on the order of approx 50 bundles of our own, but workflow goes like this:
First, we have a target platform that contains all third-party and Eclipse bundles, Eclipse takes care of downloading & managing them. Then, the workspace has all the bundles of the project, grouped in 3-4 working sets. Compilation happens as usual on save, sometimes GWT needs to be recompiled, but even then the changes get picked up immediately because no deployment needs to happen - the running Equinox system uses the unpacked project folders as bundles. Running this from within Eclipse gives us hot code replace, on-the-fly changing template files, only MANIFEST.MF/plugin.xml changes need to refresh the bundle - and even then it's usually faster to just restart the framework than to type in the console.

if you use Eclipse Eclipse Libra may be useful for you. Libra can start Felix, Equinox and Knopflerfish inside Eclipse as any other server with WST. They have some youtube videos how to use it.
I also wrote some tools that can help:
An osgi bundle that picks up OSGI services that match the filter (osgitest=junit4). With that you do not write Junit classes but you can provide pre-configured objects (e.g. with OSGI Blueprint). JUnit than runs based on the annotations provided in the interface your service implements.
A maven plugin that has the following useful goals
Start a OSGI containers and deploy the bundle maven project with all of it's dependencies (which are OSGI bundles of course). The OSGI container starting is done with the help of PAX Exam but the JUnit tests are started with the help of the OSGI bundle I wrote (that runs the OSGI services you may provide).
Create a folder that contains a shortcut to all dependencies of the project (located at the maven repo or target directory of the folder)
If the projects are deployed onto the server (Eclipse Libra) I have to say only update X where the X is the id of the bundle and everything is refreshed rapidly. You do not have to re-compile the projects that are published to the server if you run Equinox in Libra as it points to the target classes folder which is refreshed as soon as you save your class or pom.xml.
If you do not publish your project onto the server but add it as a bundle in the container pointing to the shortcut folder you can also run the update command on the OSGi console after running mvn install (without the restarting of the server).
A step-by-step guide is available at http://cookbook.everit.org/
With the following method above it is possible to write tests as TDD tests and run them as part of a maven compile on the CI server.
I hope you will find these tools as useful as I do!

It depends on the platform under Karaf: Felix or Equinox.
Equinox
Eclipse has excellent (or almost excellent) support for launching Equinox with bundles of your choice. The two things you need to prepare are:
Bundles, being developed, available in the workspace as Plug-in projects
Target platform, containing the remaining bundles of the application
Such setup will allow you to easily make changes to your bundles, even runtime and easily restarting the runtime when this is required. I see Karaf as more suitable when you are developing on remote system, where the bundles are deployed via SSH or FTP or when you are using external build tools like Maven, which have ability to automatically copy the bundle in the runtime after it is built.
If you are using Equinox, this will give some extra edge over as the runtime will execute the code directly from the workspace.
Felix
Felix doesn't seem to have such support for launching from Eclipse (although there is a work toward this, tracked in this Jira issue). You can also launch it as normal Java application, but this is far from convenient. In this case, using Maven will be much better alternative. You can still setup Eclipse to take full advantage of the PDE other features, only launching will be done externally.
Summary
In summary, you can always automate everything through Maven and Karaf will greatly help you in this regard. Eclipse will give a little edge, if you are using Equinox. You should be able to have hot-code replace regardless of the method you are using, because the hot-code replace doesn't even consider OSGi at all (except in the only case, when you reload your bundle and fresh class loader is created).

A recommended way to use Spring application context within Eclipse RCP project

what would be a recommended way to work with Spring application context within Eclipse RCP project.
I have a Swing based application that is wired together by Spring and its configurations. What would be the best strategy for these two, without too many conflicts between them (I'm just beginning with Eclipse RCP, and I am mostly worried about how similarly eclipse plugin.xml looks in comparison with xxx-context.xml.
Thank you for help.

I think the best way to use Spring in Eclipse RCP project is to use it with Spring Dynamic Modules. I define beans in diffrent contexts over the plugins and export some of them as osgi services to allow beans from other plugins use them in dependency injection. Also I implemented some kind of ServiceAccessor (singleton wrapper over osgi service accessor) that displays "waiting services to be registered" dialog to user until all necessary services will be registered.

Achieving Eclipse-like OSGi launcher

I am building an OSGi application and need to create an Eclipse-like OSGi application launcher.
For those who do not know, when an OSGi application is run through Eclipse's OSGi framework, Equinox launches and automatically manages the order of bundles being started and stopped. From what I have experienced so far, it seems to be very efficient in what it does.
I want a similar piece of software to be able to create powerful distributable OSGi applications that can take a dynamic group of bundles, and without rewriting any code, start the application correctly and in the right bundle order.
I am curious to know how Eclipse achieves this result efficiently and how I can achieve the same result.
Thank you,
Steve

You have two options:
1) use pax runner
2) Use eclipse bundle witch serves as starter ( i believe it's org.eclipse.equinox.launcher)
Edit:
1*)For equinox options starter see this link paragraph Configurations and all that... BTW I've been wrong it's not launcher bundle it's common and update bundles.
2*)Fox pax runner example see this screen cast