Maven Support in Bndtools — Future Directions
Enhancing support for Maven is a perennial topic amongst Bndtools developers and users, and during the Bndtools Hackathon last week we discussed the topic in-depth. As a result, we have determined that there will be two broad approaches towards Maven support in Bndtools. The choice between these approaches will be largely a matter of taste, and the user’s attitude and motivation towards the tools.
One set of developers comes from the Maven world and is generally happy with the “Maven Way”; they do not want it to change significantly. We feel that these users are already well served by the Felix Bundle Plugin, m2eclipse and even other IDEs such as NetBeans.
Bndtools cannot and should not compete with those tools as a generic Maven-centric IDE; yet we can still add value. For example even when using m2eclipse, we can offer our wizards for creating Declarative Services or Blueprint components, and we can provide a great way to launch, test and debug OSGi applications from within the IDE.
Also our support for the OSGi R5 Repositories and Resolver specifications means that you can work with bundles built by Maven and deployed to a repository – e.g. Nexus, Artifactory, or even just the bundles installed in your “local” repository – resolve your top-level bundles and generate an application descriptor. This descriptor can then be fed back into the Maven build chain to create a fully assembled and deployed application. We feel we can do a much better job of this than other tools because we take full advantage of OSGi’s rich Capabilities and Requirements dependency model.
We call the above a “Maven first” approach. To make it work, certain parts of Bndtools will have to be decoupled from the internal build system so that, for example, we can resolve and run without having to be inside a bnd-style project. This decoupling is anyway good for Bndtools’ internal modularity, and we expect to complete it in time for the 2.2 release.
The second approach is for developers who prefer a more OSGi-centric development process, and who want to use the advanced build-time features of bnd/Bndtools while still using a fully Maven-based offline build.
For example one of the most exciting features we are working on in 2.2 is baselining, which (briefly) means the tool helps to ensure your packages and bundles are correctly versioned according to the OSGi Semantic Versioning guidelines, by breaking the build when versions are incorrect, and offering quick-fixes to get it back into shape. Ferry Huberts has written an overview on his blog.
Another feature that Bndtools has always offered is very fast incremental builds, which are integrated with the launching subsystem so that your code is compiled, built and already running in your application as soon as you save it. Incremental building is always a problem with Maven, and even m2eclipse doesn’t do it very well (though it seems to be improving gradually).
These features are hard-to-impossible to implement given the control (or rather, lack of control) afforded to us by the existing Felix Bundle Plugin. That plugin basically only creates the JAR file during the packaging phase, whereas in Bndtools bnd maintains the build model so that it can be used in Eclipse, Ant, Maven, Gradle and others.
Therefore we are working on a new plugin for Maven that allows bnd to take more control. We call this the “bnd first” approach. Actually the plugin was started by Toni Menzel, and Peter Kriens has begun enhancing it. So far it looks extremely promising, but unfortunately it is still quite experimental and will probably not be release-quality in time for 2.2. If you are interested in trying it before then, please engage on the Bndtools mailing list.
As ever, enhancing Maven support does not mean that we are reducing our support for existing Ant builds. We will continue to offer a modular Ant-based build system with our project templates, and in fact some of the work done at the hackathon by PK Søreide helped to improve the performance of our Ant tasks by a factor of three to four.
Also, Paul Bakker worked on a new Gradle build template, which turned out up to ten times faster than the old Ant build! We hope to have this ready in 2.2.
So our focus continues to be this: enabling you to be as productive as possible as an OSGi developer, irrespective of your choice of build tool.