Neil Bartlett on Simplifying OSGi Development with BndTools

1. I’m Alex Blewitt at QCon London 2012 with Neil Bartlett creator of BndTools. So Neil tell me about your background and how you got involved with OSGi?

I started developing with OSGi in about 2004; got into it through Eclipse plug-in development and Eclipse RCP applications, and from there pushed down the stack to more general OSGi applications, server-side, headless and so on. I’ve been working with it most of my career since then.

2. So Eclipse obviously is well known for being an OSGi application since version three, and it’s got the plug-in development environment tools, or PDE tools which let people to create OSGi bundles and plug-ins, what do you think, the things with PDE are that led you to create BndTools?

I have a lot of experience with PDE, having starting developing OSGi using that, and really there are some issues with it in terms of the amount of additional information that you have to explicitly supply as the developer, such as all of the imported packages, and you know, most of the information is really duplicated, we have all of the imported packages available in the Java source code and in the byte code. So what I really like about the alternative approaches that come from the Bnd tool, that information can be extracted from the source code that developer doesn’t have to maintain it in multiple places. Of course we know when we maintain information in two places it can very easily get out of step, so I just find it very difficult to reliably produce accurate and good quality OSGi bundles with that tool, and that let to my usage of the Bnd tool.

3. So what is the Bnd?

So Bnd is a tool that was originally created by Peter Kriens for the use of the OSGi Alliance, so the Alliance they use that to build their reference implementations and the compatibility test kits that they built every night as part of their continuous integration. And so Bnd you can think of it as the replacement for the JAR tool from the JDK, whereas the JAR tool produces JAR files, Bnd produces bundles, and it produces bundles with valid manifests, where that manifest has been generated to include all of the dependency information, uses constrains, expansion of wild cards and things that aren’t valid in a directly edited manifest that is required by OSGi, but can be easily inferred from the code that goes into the bundle.

4. So BndTools built on top of Bnd, how does BndTools work in terms of managing Bnd’s create Bundles?

So BndTools is actually a relatively thin layer, it triggers Bnd at the appropriate time when we detect that, for example when a Java source file has changed or one of the Bnd descriptor files has changed. It triggers Bnd to rebuild the bundle, so we always have the OSGi bundle ready and built, that is the first thing that it does. The second is that provides you runtime, a debug and launch environment, so you can launch those bundles and they will be continuously updated in that runtime as you change them in the IDE, so you get a kind of hot-swap effect while you are developing, which is very convenient. The third thing that we provide is assisted graphical tooling for editing the Bnd descriptors, analysis of bundles so you can very quickly see what the dependencies and the exports of a particular bundle may be.

5. Of all of these things it’s no surprise that the BndTools has been nominated as a finalist for the EclipseCon Best Conference Tool for this year, what is the roadmap looking forwards for BndTools over the upcoming year?

A very important part of what I see is that development life cycle is a repository-centric viewpoint, so BndTools is supporting OBR. We currently have support for OBR, which is the OSGi Bundle Repository. OBR is stands at the moment is fairly informally specified and a little bit limited, the OSGi Alliance right now is defining the specification for a new OBR, a new Repository format, that gives a very powerful way of resolving dependencies in advance of creating a runtime. So in that’s an extremely powerful way to build larger applications out of the smaller component that are OSGi bundles. [Editor: The OBR specification has been released as part of OSGi 5 since this recording was made.] My roadmap for BndTools at the moment is to support the new OBR specification releasing to repositories and sucking bundles in from repositories and launching and integrating also the OBR resolver.

6. That is great, so in terms of the licence - presumably it’s OpenSource - is there anywhere that people go to download and build it themselves, you take contributions, is that developing mailing lists and so?

Sure, BndTools is Eclipse Public License, Bnd is Apache License, both of them are hosted at GitHub under the same GitHub Organization and certainly we are very interested in receiving contributions and comments and so we have an issue Tracker is on GitHub and we have an open mailing list as well.

7. So obviously you mentioned that the BndTools is under the Eclipse Public License and integrated with Eclipse. Looking down the line do you think that other IDEs like Intellij and maybe NetBeans are going to be capable of producing bundles with either BndTools or Bnd?

So BndTools is obviously an Eclipse Plug-in and so BndTools itself won’t work in NetBeans or Intellij. However Bnd is really becoming a very widely accepted as an approach to building bundles, and the Bnd descriptors you can consider them like a kind of lingua franca for describing Bundles. So many build tools are already using that, for example the Maven bundle plug-in uses Bnd and there is a plug-in being developed for Intellij called Osmorc which also uses Bnd, and I believe NetBeans tends to go through Maven a lot so they would use the Maven Bundle Plug-in. Certainly if you are developing in BndTools that should be the ability to work nicely with other developers that are using other IDEs.

8. So how can people use BndTools to help from an existing Java project to more OSGi compatible run time?

BndTools can certainly help you to start taking Java projects and adding OSGi metadata to them by analyzing the JAR files that you have, discovering the dependencies and adding those manifests to JAR files, and that as the first step can be available, because you then know about the dependencies even if you aren’t enforcing them by running them inside an OSGi environment. Then you can look at various ways of gradually migrating to OSGi. One of the most interesting ways is probably a services-first approach, where we can use something like OSGi Declarative Services as a dynamic dependency injection system, and use that without necessarily running on a full OSGi framework using something called Pojo-SR, which is essentially the OSGi service layer without the module layer underneath. And then later you can look at starting to carve out bundles and really enforcing the dependencies that exists between your modules.

9. So the future of OSGi in a cloud is obviously looking up, there is a lot of products out there that have the ability to deploy OSGi applications across a cloud environment, tell me how you see BndTools fitting within OSGi and clouds?

So for me the big advantage of OSGi in the cloud is that when you deploy a bundle to the cloud you have a very clear visibility of all of its dependencies, all of the capabilities that it provides and using a repository technology such as OBR that we talked about, we can very quickly and easily provision cloud nodes from an automated console and in a centralised way. So that’s why we see a number of cloud products. There’s my own company’s products - the Paremus Service Fabric - and several OpenSources efforts as well. BndTools is supporting those. I’m awareof some of my companies competitive building products on top of BndTools to deploy to their own cloud products, and of course I’m building products for my own company as well based on that. So we will be supporting cloud in many ways through the idea of repositories and rapid deployment.They all fit very nicely with the cloud.