What Osmorc can learn from Bndtools

So the next few sections shall put some light on features I very much liked about bndtools. After each section there are some bullet points indicating how these features might be added to Osmorc in the future:

Manifest generation and/or manual editing

From what I saw, bndtools is mostly about code first and generating manifests, which is IMHO the only sane way to develop OSGi. Nevertheless there are many people (also at the Code Camp) who are not happy with manifest generation for various reasons and would prefer to type them manually. So while Osmorc supports the generation aspect quite well (simply because Osmorc uses the same bnd library that bndtools is using), the manifest first approach is not supported very well. Adding in the reports on the Osmorc issue tracker, the following things should be added to Osmorc quickly:

• Dependencies of modules should be updated automatically to match the imports in the manifest of the module. This is especially true for inter-module-dependencies, which are a pain to set up if you have a bunch of modules. This however is less of a pain point if you use Maven for building, as Osmorc can and does automatically import maven dependencies.
• The editor should be aware of missing unreachable classes/packages and offer to add them to the manifest.
• The manifest editor should point out, when importing packages that are not exported by another bundle in your project.

Dependencies

In general dependencies seem to be a major headache. Bndtools uses some kind of repository folder, where dependencies can be put. That means, if I need a new dependency, I need to download a Jar and put it into that repository folder. After that, bndtools can calculate the dependencies from the manifests and automatically update Eclipses project files so the compiler finds it's dependencies. This worked really well. In Osmorc you have to add your dependencies manually by adding the library to the module (which doesn't differ much from the way it's done in bndtools) or use Maven for dependency management (which is the recommended and imho easiest way). Still there is room for improvement:

• The whole idea of the framework instance (aka target platform) is actually not needed and causes confusion. The idea behind it is, that if you want to build your application on top of an existing OSGi platform (e.g. for Eclipse RCP development), there should be an option to easily add all dependencies for this platform to your project. The "framework instance" concept however does not do this in a very convenient or understandable manner. I'd like to pursue the idea of project level libraries for this. That is, if you want to use the Eclipse RCP framework, you can add a project level library to your project and reference it in your module. If you use Maven, you'll simply add your dependencies to your pom.
• When you start a new project, you will almost certainly require a dependency to the OSGi core lib. Osmorc should suggest to download it or modify your maven project to include this dependency.

Running and debugging

Running and debugging is done very well in bndtools. I like the hot deployment of changed bundles without the need to restart the whole OSGi runtime. However there were times, when we had wished for more control over when a bundle is hot deployed.

• Hot deployment should be added to Osmorc. To prevent accidental deployments one could ask the user if the compiled bundle should be redeployed (in a similar fashion the debugger asks to hot-deploy changed classes).

Bundling

Bndtools supports an arbitrary amount of bnd configuration files that can be applied on a project. That way it is possible to create several flavours of the same bundle (e.g. one for the testing environment and one for production).

• In Osmorc you can currently have only one facet per module. I'd like to keep it that way, because the facet is required to determine your manifest settings and having multiple of them would be confusing at least. However IntelliJ has an artifact facility which allows for building arbitrary artifacts from your project. This facility should be extended to support OSGi bundles, so you can build many different artifacts from the same module, which is just the same thing that bndtools offers. As a bonus, it would be nice if one could launch the artifacts in a run configuration.

So there is lots of work to be done, and I intend to get most of this working with Osmorc's 1.4 release that will ship with IDEA 11. Stay tuned for updates.