Q&A – Neil Bartlett, Bndtools creator
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
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
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
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
Bndtools is of course linked to Peter Kriens’ tool bnd.
What functionality does bndtools offer in addition to
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
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.