OSGi is a specification for a component system. It lays out the rules to write highly modular software that will remain easy to maintain even if the application grows. It achieves this with bundles and services. Bundles are JARs, and are the traditional modules; services provide an interconnecting framework that keeps the components in the bundles uncoupled to each other.
To achieve its magic, OSGi needs metadata, most of this metadata is in the Bundle’s JAR Manifest. Maintaining this metadata was an undesirable chore. Therefore, Peter Kriens (aQute), at the time the Ericsson representative in the OSGi Alliance, developed bnd to analyze the Java classes and used this information to generate the Manifest. Richard S. Hall (the developer of Felix) and Peter Kriens worked together to make a Maven plugin with bnd for the Apache Felix project. At one time, this became one of the most popular plugins in Maven Central since it made it almost trivial to add and OSGi Manifest.
Neil Bartlett, one of the pioneer OSGi users, saw how bnd could be used to simplify the development of Eclipse plugins, Eclipse was based on OSGi since 2004. He, therefore, wrote a promising Eclipse plugin that leveraged bnd. Around the same time, Peter Kriens had also started a bnd based plugin. However, Neil’s Eclipse experience was much better. More, Peter had not automated the build process because he was afraid it would be slow, you needed to call up a menu, while Neil had perfected the process. After some headbanging, and a hotel meeting on Heathrow, Neil & Peter decided to join forces.
One of the most important drivers of bnd & Bndtools was the OSGi build. The OSGi Alliance is forced by its bylaws to provide a Reference Implementation (RI) and Test Compatibility Kit (TCK) to ensure that the specification can be implemented (the RI) and that any implementation can be tested against compatibility (the TCK). Since Peter Kriens was the OSGi Alliance Technical Director, he used bnd to control the build of these software artifacts. This was a nice learning ground for bnd. TCKs require not only testing good cases, but they also require testing the reactions on bad cases. This has given bnd its wide range of instructions.
Originally, bnd was developed to create the manifest for bundles. The bnd.bnd file described the bundle and then it was bnd’s task to collect the parts and create a JAR with a proper manifest. The compilation and other aspects of the build process were initially left to Ant, a once-popular build tool. However, this created a tension between the Eclipse IDE and the ant tool. The creation of the JAR is very sensitive to the build path, the JARs that the different build components use. A continuous integration tool is paramount to build reliable systems. However, we developers tend to spend most of our time in the IDE.
This tension drove bnd to become a headless build model. Tools like Maven, Eclipse & Gradle combine a build model with a build driver. Since we needed to use the same model in both the IDE and the continuous integration tool, we needed a shared model that could be executed by different drivers. This btw is a common problem. Currently, the trend is that the command line tools have won. (Look at the Javascript world.) The biggest mistake of Eclipse has always been that they did not include a good continuous integration tool, leaving this ‘detail’ up to the developers. Too often, the results inside the IDE differed from the continuous integration and that is lethal for any development process. This is primarily because it is a 100x times easier to add a function to a command-line tool than to an IDE. Most IDEs decided to give up on an internal build model and started integrating with the command line tools, the lowest common denominator. Intellij turned that approach into an art. Although this has many advantages, it will also always show through the seams.
At Bndtools we’re still resisting that trend because we believe that, although command lines are crucial, you spend most of the time in the IDE. It is therefore worth optimizing the IDE; if you use Bndtools you very likely agree.
This meant that bnd had two distinct faces. On one side it was a tool to create a manifest out of a set of classes. Its other face was an abstract build model with drivers in Maven, Gradle, Eclipse, Intellij, and likely more environments than we know. For this reason, bnd is extremely easy to integrate, it has no external dependencies.
Around 2012 the number of committers increased significantly. Ferry Huberts, Marcel Offermans (Luminis), Paul Bakker (Luminis), PK Sørelde (Comactivity), Raymond Augé (Liferay), Carter Smithhart, David Bosschaert (Adobe), Tim Ward (Paremus), David Jencks (IBM), BJ Hargrave (IBM), and some others.
In 2012, bnd was used extensively to experiment with OSGi. Peter Kriens developed the Declarative Services annotations, the type converter, the configurator, meta-type annotations, baselining, and many smaller innovations that later became OSGi specifications. Neil Bartlett experimented with using the resolver as an assembler of applications, something that is one of the most unique selling points of Bndtools, and PK Sørelde developed a release tool.
Until that time, bnd was still used in the aforementioned Apache Felix Maven plugin. However, the fact that this plugin was on another release cycle, and had bad defaults (according to us), caused much pain. We, therefore, decided to take over this plugin in the bnd project. This attracted several people that were very interested in the Manifest creation and Declarative Services support in bnd, but were not interested in the abstract build model and IDE support. We, therefore, created several plugins that provided most of bnd’s functionality via Maven.
Around 2015 BJ Hargrave from IBM joined the project in anger; he is now one of the driving forces. He professionalized the build, introduced many of the rules we (try to) adhere to today and started a massive cleanup project. Up until then, most of the work in bnd was done ‘on the side’. Having a workspace with a thousand projects on Bndtools was an important IBM incentive to make Bndtools better.
BJ was also the driver behind Gradle. He developed a plugin that drives the continuous integration build of bnd and any Bndtools user. Any workspace useful in bnd includes a Gradle build that does not require any specific setup. However, he also created a plugin that left the building up to Gradle and only created the Manifest and Declarative Services XML, just like the Maven plugins.
Although bnd has a history of 20 years in 2020, the project is very active and very much alive. Some committers went, and some committers joined us after many high quality commits. Thanks to Github, we can take several PRs per week. Thanks to the involvement of the OSGi members, bnd keeps tracking the latest developments in OSGi and Java. We closely track issues with a two-weekly call. Using LGTM we can keep the quality high: A+ for a relatively large project.
Our primary goal is to create a good IDE experience that includes a perfect continuous integration. The goal is to never have to run to the command line tools. This is a very ambitious goal that has been given up by many. Nothing is ever perfect but we’ve come quite far we think.
Developing with Bndtools is fun. The code-debug loop is unsurpassed. Using the dynamics of OSGi, we transparently replace the code on the target immediately after any change in the source. This works in a local process, but it also works on a remote machine. You really have to see it to believe it …