Q&A – Neil Bartlett, Bndtools creator

Chris Mayer

We speak to the Eclipse enthusiast about the first stable release of the IDE, based on Eclipse.

Can you describe the bndtools project in a few words? Why did you decide to create bndtools?

Bndtools is an IDE, based on Eclipse, that enables easy and rapid development of OSGi bundles and applications.

What is new in bndtools 1.0.0 compared to the previous preview versions?

This release is mostly about stability. With the help of a small team of developers and a larger number of brave alpha testers, we have ironed out many of the bugs that existed in previous releases. In particular the incremental builder is much more reliable, and inter-project dependencies work in a more natural way.
Additionally this release uses OBR (OSGi Bundle Repository) to statically prepare fully resolved runtime descriptions, which give us a high degree of confidence that the runtime when we launch it will actually be able to resolve and run.

The release also contains the automatic semantic versioning feature, which allows exported package versions to be calculated by the tool as part of a release process. I see versioning as critical to managing the evolution of a large software product: the version we attach to an API is the best and most concise way of communicating the scope of changes, but tools need to support developers to make sure we communicate this information accurately.

This is the first Major Release of the tool. Does this mean the tooling is complete and production ready?
I don’t believe that any tool like this can ever be truly “complete”, there’s always something more that can be added! However the current version does cover all of the common requirements for OSGi development, and it is stable enough that many developers are already using it in production for their day-to-day OSGi development. Also of course, we use Bndtools to develop itself.

Does it integrate with other environments?

Bndtools projects can be built from the command line using bnd, and we use ANT to drive multi-project builds. Because bnd is used or embedded by many other tools in the OSGi ecosystem we find that many of those tools work fine on Bndtools projects as well. For example the most popular approach for building OSGi bundles in Maven is with the Apache Felix Bundle Plugin, which embeds bnd and can use the same descriptor files as Bndtools.

Within Eclipse we interact with the Java Development Tooling (JDT) in a fairly standard way, so other IDE plug-ins tend to work with Bndtools projects. For example Bndtools has been used to develop OSGi bundles in other JVM languages such as Scala, Groovy and Xtend… it’s even been used in conjunction with Google’s Android tooling.

Bndtools is of course linked to Peter Kriens’ tool bnd. What functionality does bndtools offer in addition to bnd?

It’s basically the difference between using an IDE like Eclipse for Java development versus using the “javac” compiler directly from the command line. Bnd is very powerful, but it still needs to be triggered to run, and you have to edit script-like descriptor files; a plain text editor doesn’t give you much help with that.

Bndtools takes care of invoking bnd whenever the inputs to a bundle are changed, which ensures that the bundles on the file system are always up-to-date with the Java sources. It also offers GUI-assisted editing of the descriptor files, along with lots of help in launching, testing and debugging OSGi runtimes.

OSGi development in general is considered to be a difficult task. How can tooling change this situation? Is there still room for improvement ? 

Definitely, in fact I firmly believe that OSGi development can be made *easier* than traditional Java development. I also believe that Bndtools is making good progress towards this, and I already find it very painful to go back to plain Java development where I can’t rely on things like OSGi Services, package encapsulation, dynamic configuration, etc.

We still have some way to go before OSGi is sufficiently intuitive for the majority of Java developers, but we’re getting there. One of the biggest stumbling blocks is the need to declare package dependencies in the MANIFEST.MF of each bundle, but this information is already available in the Java sources and compiled class files, so bnd extracts this information and generates the MANIFEST.MF. This is far better than requiring developers to maintain two separate sets of dependency declarations.

Unfortunately one area where tooling doesn’t help very much is in dealing with existing libraries that are not yet available as OSGi bundles. Particularly problematic are the libraries that use class-loading hacks or try to take over the lifecycle of the entire application. This issue needs to be solved by gradually improving the quality of these libraries — or sometimes building better replacements — and with the rise of bundle repositories.

What are the next steps for the project?

First we’re expecting to put out micro-version releases more frequently, to address bugs as they arise.
Longer term, we will be transitioning to the standardised form of OBR when it is released by the OSGi Alliance next year.

We will deepen our integration with Maven for those users who build with Maven, though continuing to support ANT and other build tools. We will also explore adding support for launching to the cloud, and building OSGi sub-systems.

Finally we would like to offer advanced visualisation of bundle dependencies and services, both statically and through dynamic introspection of a running OSGi application.

There’s also the question of whether to move Bndtools to an open source foundation such as Eclipse or Apache, but that is still being discussed amongst the Bndtools committers.

Inline Feedbacks
View all comments