BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News BndTools provides OSGi Development in Eclipse

BndTools provides OSGi Development in Eclipse

Neil Bartlett has released BndTools 1.0.0, an OSGi development environment for Eclipse. Available as source code via its github repository, the tools can also be installed directly into an Eclipse runtime from the Eclipse Marketplace.

BndTools provides a way of developing OSGi bundles with Eclipse. Instead of defining dependencies by direct editing of the Manifest.MF, it uses Bnd files to drive a toolchain based on the Bnd tool. An introductory tutorial is available. Additionally, BndTools can also take care of automated semantic versioning, by comparing the built component to a previously released component, leaving decisions about whether to increment the micro, minor or major number an algorithmic instead of human decision.

InfoQ caught up with Neil Bartlett, and began by asking why he created BndTools:

Neil Bartlett: I do a lot of OSGi training and always had a problem with the tools for OSGi development being unwieldy and difficult for beginners to understand and use. Since I had some experience with Eclipse plug-in development, I started to build small utilities that made life easier for me and my students. Over time these tools grew into a fairly complete, integrated development environment for OSGi.

Today I use Bndtools for all of my OSGi development, and since Eclipse plug-ins are based on OSGi I even use Bndtools to develop itself.

InfoQ: How does it relate to Bnd?

Neil Bartlett: Bnd is an extremely powerful but low-level tool for building and analysing OSGi bundles. It was developed by Peter Kriens (the OSGi Alliance's Technical Director) and is used by the OSGi Alliance to build their own suite of API, compatibility test and reference implementation bundles. As a low-level tool it is easily embeddable and can be called directly from the command line, used an ANT task, or embedded in Maven and IDEs.

Bndtools uses bnd as its "engine". All of the smarts are in bnd essentially, and Bndtools just figures out when it should call bnd and presents the results nicely. Because many other tools embed bnd, the descriptor files used by bnd have almost become a de-facto standard, meaning that it is easy for a Bndtools developer to collaborate with developers using other tools, or to migrate permanently to another tool if they choose.

InfoQ: How does BndTools compare to Eclipse's PDE?

Neil Bartlett: Eclipse PDE is another OSGi development environment based on Eclipse. Bndtools does not reuse PDE in any way, but both Bndtools and PDE are built on top of Eclipse's Java Development Tooling (JDT).

PDE follows a different philosophy to bnd and Bndtools, called "manifest first". In PDE you directly edit the MANIFEST.MF file that goes straight into the bundle without any post-processing. Our philosophy is that the MANIFEST.MF should be treated almost like a compiler output: i.e., it should be generated from a simpler source artefact. This is important because a full MANIFEST.MF contains quite a lot of duplicate information or information that should be derived directly from the Java code, for example the list of packages-level dependencies. Manually editing such information is laborious and error-prone.

InfoQ: What advantages are there of using OSGi over JRebel and an ordinary Java project?

Neil Bartlett: JRebel is a powerful tool for speeding up redeployment of code during development, but it does not provide any kind of module system, either at runtime or at build time. OSGi provides enforcement of module boundaries via encapsulation and controlled, explicit dependencies. OSGi is all about improving the architecture of your application and creating reusable components, whereas JRebel is about getting your code out of the IDE and into the Java EE application server as quickly as possible.

As it happens, OSGi also features dynamic hot-swapping of modules, which works well enough that I don't regard JRebel as being particularly useful when developing for OSGi. Bndtools helps with this as well: as soon as you save a change to a Java source file, the code is recompiled, packaged into a bundle and pushed into the running application.

InfoQ:Does BndTools integrate with other build environments such as Maven and Ant/Ivy?

Neil Bartlett: Bndtools' "native" build system is bnd itself, which leverages Apache Ant for multi-project builds, and this is the way the OSGi Alliance builds their 1300+ bundles. Bnd has a pluggable repository system allowing us to use arbitrary back-end repository technologies, including Ivy.

For Maven users the most popular approach to OSGi development is to use the Maven Bundle Plugin, which is another tool that embeds bnd. Bndtools integrates with Maven via this plugin and via M2Eclipse. In this scenario, M2Eclipse subsumes responsibility for managing the build depdendencies (in the POM, obviously) and for actually building bundles, but Bndtools continues to add value by providing a way to edit and analyse bundle descriptors and dependencies, and a way to setup and execute run configurations.

InfoQ: Are there any tutorials available for getting started with BndTools?

Neil Bartlett: Yes, check out http://bndtools.org/doc/tutorials/.

InfoQ: Can you use BndTools to write plain Java code, without a code-time dependency on OSGi?

Neil Bartlett: Yes, Bndtools encourages you to use OSGi Declarative Services to write components in a POJO style, with no dependency on OSGi. As a result these components can be unit-tested outside of OSGi, and used in production in a non-OSGi environment such as Spring or JavaEE.

You may even find that Bndtools' features for configuring modules and analysing dependencies are helpful for improving the modularity of your code, even if you are not ready to actually deploy onto OSGi yet. For example, PojoSR can be used to provide an OSGi-like service registry, and it supports most of the features of OSGi except for the strict enforcement of module boundaries. It therefore helps with migrating legacy applications to OSGi, and by developing in Bndtools you can see how close you are to being able to run on full OSGi.

InfoQ: Is there likely to be any support for BndTools in other IDEs such as IntelliJ and NetBeans?

Neil Bartlett: Bndtools itself is tightly bound to Eclipse and will not support other IDEs. However other IDEs are starting to integrate with bnd, making it fairly easy to interoperate with them. For example, IntelliJ has the Osmorc project that uses bnd and has a similar philosophy to Bndtools in many ways. I have begun a collaboration with the lead developer of Osmorc to make it easier for developers using each IDE to work together.

Last time I inquired, the NetBeans project did not have plans to support OSGi development directly. However NetBeans is very focussed on Maven and OSGi developers using NetBeans tend to build with the Maven Bundle Plugin, which as already mentioned is also Bndtools' primary route for Maven integration.

BndTools can be installed via the Eclipse Marketplace.

Rate this Article

Adoption
Style

BT