The Eclipse Bundle Recipes project (EBR) was created with the intention to develop and host a technology and recipes for creating OSGi bundles out of regular non-OSGi Java libraries. Unfortunately, not a lot has happened after it’s creation. Frankly, as the Git repository and the history unveils, it has been just a code drop of the SpringSource Enterprise Bundle Repository recipes. I’m here to change that!
As an Orbit committer, it’s has been my pleasure to convert Java libraries to OSGi for quite some time now. If you know how Orbit bundles are created, you know it’s an exercise. Thus, I also have a high motivation for the Eclipse EBR project to be successful. Last week was one of those where I looked at upgrading a few of the Orbit bundles I’m maintaining. Turns out, the libraries are actually quite active and – as every good OS project does these days – they also release very frequently. That’s really turning into a boring exercise. Thus, I decided to craft together a process that would simplify things for me.
The result is very promising. With just one nice little Maven plug-in I created, a small Maven POM and an OSGi BND descriptor file I’m now able to consume the libraries directly from Maven central (or whatever Maven repo they come from), push them through a filtering step which may remove or add files, generate the OSGi manifest headers, add p2 metadata information and deploy them back into a Maven repository (eg. a local one). Then, in a second step, I’ll let Tycho run and it creates a p2 repository where the bundles are published together with a source bundle containing the library source code. Done.
Over the next few days I’m hoping to make that available in the EBR Git repository.
For the time being I pushed it to Github*. I first need to review the dependencies and push them through the Eclipse.org IP process. Once that is done, we should have a pretty neat solution for EBR. However, remember that EBR will only host and distribute the recipes, not the actual libraries. You have to generate them yourself.
For Eclipse projects, this is where Orbit comes back into the game. Orbit can take and run the recipes of all IP approved libraries from EBR (or create its own) and publish the bundles as today in p2 repositories.
: Update, Feb. 28
I pushed the Maven plug-in as well as the first recipes to the Eclipse Git repository. You can browse them at
2nd Update, July 8 2015
The EBR project is available at github.com/eclipse/ebr. Submit pull requests for all the recipes you create!
No plans for Monday morning? Interested in learning building web apps with EclipseRT? If you are around Santa Clara on Monday March 21st then please join us at EclipseCon!
Our three hours tutorial will introduce you to the key concepts for developing web applications with the OSGi HttpService, the Equinox ServletBridge and Virgo. Virgo is new this year and we are happy to have Glynn and Christopher joining us and talking a bit about Virgo.
We’ll also have a great set of exercises. Thus, please bring your laptops with you and make sure its battery is loaded. All you need is a vanilla Eclipse SDK 3.7 M6 and a JDK on your system. But don’t worry we’ll also have a way to distribute the necessary pieces on site.
Monday, March 21st, 9am
EclipseCon 2011, Ballroom A
See you there!
There is a nice SpringSource blog about their plans for building OSGi applications. Actually, it’s more an advertisment for their tool called bundlor which basically has the same purpose as bnd but is implemented in a different way.
There is one point in the blog the I don’t like at all. It’s yet again I hear the myth about automatically generating OSGi bundles from 3rd party libraries and how successful it is used in the SpringSource bundle repository. Folks, it might work for one 3rd party library but it will never work in an automated way for all 3rd party libraries. There are just too many issues around OSGi-fying 3rd party libs which need to be addressed carefully. If the library deals with class loading you might be out of luck no matter how great your generated manifests look like. You need to modify your source code and/or patch the 3rd party library to make it work correctly. Even better, sometimes there are multiple ways to convert a 3rd party library into an OSGi bundle. A stubborn one-to-one conversion process cannot incorporate that. It may depend on your requirements and preferences.
The process is not finished with generating manifests. Be aware that this can cause broken bundles. Those issues are fixable. But this example shows that every library requires careful attention.
Who else read RFC 124? It has a really funny title: “A Component Model for OSGi”. Yeah, that really speaks for itself. Just repeat it a few times and let it settle for a while. So, RFC 124 wants to create a component model for a component model. Funny, eh?
But is that really what people need? Maybe I just don’t get it but I thought the real problem was that programming OSGi is too verbose.
Well, I’m certainly not arguing against that. Programming OSGi is verbose. When creating services you need to write additional code to maintain their registrations. When consuming services you need to write additional code to track available services. Last but not least you need some plumbing around. Continue reading OSGi RFC 124