Monday, March 30, 2015

Yet Another Maven Bundle Plugin!

It must have been 8 years ago that Richard S. Hall visited me here in the south of France. During these days we hacked together a rudimentary plugin for Maven so that Richard could use bnd's functionality in his maven build. This was where we laid the foundation for the "funky" XML that described the bundle. As this was our first maven plugin, we had no clue what we were doing but it seemed to work for Richard. It is now 19 releases later. Surprisingly, the Apache Felix bundle plugin is one of the most popular downloads outside the standard Sonatype maven plugins. 

That said, the plugin was showing some strains that were not easy to correct in an existing plugin for backward compatibility reasons. Therefore, last week Neil Bartlett published a new variation on this plugin in the bndtools project.  This plugin fits better in the maven model, instead of taking over the JAR process it now only outputs the contents of the JAR in the classes folder. This fitted better when you had later phases that further processed the classes directory. Neil Bartlett, the author of the plugin describes the process in detail in his blog. Since we receive a lot of pressure to be more maven like, it is not unlikely that we will add more features to this plugin and bndtools to make them interoperate more closely.

Inspired by this new maven plugin, BJ Hargrave, added similar support to the Gradle plugin, making it easier for native Gradle builds to use the standard bnd plugin. Similar support was already available in ant.

The new plugins will be part of the bndtools build so that we can release the plugins synchronized with the new features in bnd so that we can publish them timely on Maven Central.

This does not mean that the older plugin will be disbanded any time soon. Since it is so popular and has some behaviors that are different than the new plugin we will continue provide support for the Apache Felix group to keep publishing this plugin.

Peter Kriens

Thursday, January 8, 2015

Java Modularity Revisited

There is a new JSR for Java modularity: JSR 376 and it is already approved by the Executive Committee. Not sure where to start, but I would love to participate in this group because the approach seems to be much more attractive this time around. Reading the short description I understand that this time packages are not ignored, but they actually are the units of export. This means that OSGi and JSR 376 will share the same basic concepts. Even more positive, the JSR clearly states that it will be made compatible with OSGi. All in all an excellent start.

That said, why write a blog when you're all happy?

The key concern is that there is currently no OSGi expert in the EG. As stated, I'd love to participate. There are a number of issues that I think will require some attention to not gratuitously create hardships for the 'sophisticated applications' (words from the JSR, not mine!)  that will use OSGi on top of JSR 376.

First there is the rather simple problem (but oh so contentious) of versioning. With OSGi and bnd we have quite deep knowledge of semantic versioning as it is used in a Java world. What we learned is that interface/contract based programming with multiple implementations creates some subtleties around semantic versioning that are not present in language like Javascript, Ruby, etc. I would really appreciate a chance to present these lessons to the EG. We might solve the biggest pain the OSGi currently has with the JVM: packages that have no version, if we can solve this problem I will not ask for anything else! (Well, for now.)

Second, the dependency model. The prevalent dependency model in software is transitive identity dependency, an archetypical example is maven. It is simple but it also creates humongous graphs. Though Maven does not download the Internet, people download the internet because it is so easy to do. This is exactly the problem we had in Object Oriented technology and interfaces gave us the tool to break the transitivity. The OSGi model provides an elegant solution in the same vein as interfaces did for objects. I am not sure if this model should be pushed completely in the VM but it would be worthwhile to have a discussion around the differences and what the consequences for the OSGi compatibility are.

Last but and I guess also least: the Service Loader. The Service Loader in the Java Platform provides a way for modules to locate classes by their interface name. This is a crucial service in a module oriented system, it allows the discovery of available implementations. However, one could ask if (ab)using class loaders for discovery is a brilliant idea or if it is a hack that looks acceptable because we're so used to class loading hacks? The drawbacks of class loading hacks for extensions are that objects are created without context, often requiring statics and singletons to communicate. There are better solutions and I think it would be great if we could address service discovery in a better, more Java oriented, way. And I do believe this a crucial part of a module system; when you put a fence around your territory you better think about the gates.

So where do I sign up?

Peter Kriens

Monday, January 5, 2015

Location confirmed for OSGi Exam in San Francisco - Jan 22, 2015

Happy New Year to everyone. We hope you had a good end to 2014 and are refreshed and raring to go for 2015.

For those of you in the Bay Area don't forget the OSGi Developer Certification - Foundation Level Exam on Thursday Jan 22 between 13.30 and 17.00. 

We are pleased to confirm that we have finalized the downtown San Francisco location of the exam and it is:

Rincon Center, 121 Spear Street
San Francisco

This is just a 5 minute walk from the Embarcadero BART station so we hope it will work well for everyone.

You can find out further details about the exam and topics that may be included on the OSGi website here.

To book a place please sign up here.

If you have any questions please email us.

Wednesday, December 3, 2014

OSGi Developer Certification Exam - San Francisco - Jan 22, 2015

We are pleased to announce the next OSGi Developer Certification - Foundation Level exam will be taking place on Thursday January 22, 2015 in San Francisco.
Picture courtesy of
Picture Courtesy of 

So if you want to test and prove your OSGi proficiency and achieve an OSGi Alliance certified level of competency then be sure to sign up here.

Everyone passing the exam receives:

  • An electronic certificate (with a unique number)
  • A 'certification badge'

Plus, the OSGi Alliance maintains a register of all Certified Developers so that an individuals certification status can be verified.

The exam is open to anyone, however we recommend that you should have gained some practical experience using OSGi and have a good understanding of the OSGi R5 specification topics that are covered in the exam (full details here).

There is a special discounted price for students, and OSGi Alliance members. Please contact us by email for discount details.

More information about the exam, logistics and the benefits of achieving OSGi Developer Certification - Foundation Level can be found on the OSGi Alliance website here.

We hope you can join us.

If you have any questions please contact us by email.

Friday, October 24, 2014

Opportunity to Learn About OSGi in Romania - Nov 21

The Bucharest JUG with Luminis Technologies and Thales Romania are hosting a free one day event in Bucharest on November 21 (Registration is mandatory, see below).

The event is titled "OSGi in One Day" and it will introduce you to OSGi technology and some of the tooling available for developing with OSGi.

The expected audience is likely to include a broad range of OSGi experience, from beginners to dedicated RCP developers to core framework developers, and so the programme has been structured accordingly.  There are 3 main parts:

  • General introduction to OSGi
  • Demo of building and deploying a cloud-aware application with OSGi
  • Hands on workshop to try it out for yourself

Marcel Offermans and Paul Bakker from Luminis will be presenting and running the workshop.

Many thanks to the Bucharest JUG for their support and assistance in organising this event.


Date: November 21, 2014

Start time: 9.00am for full day or 2pm for the Hands On Workshop

Location: Thales @ Sema Parc, River Palace, 319 Splaiul Independentei, Bucharest


It sounds like a great opportunity to find out more about OSGi, meet new people and share OSGi experiences with your peers in Romania.

Thursday, September 25, 2014

How Should I Use Guice/Spring/Blueprint Inside My Bundle?

Someone asked me over mail:
How should I use Guice (or any other injector) inside my bundle?
The short answer is: don't.

The slightly longer answer follows hereafter.

Injectors like Spring and Guice were invented because around 2000 large monolithic applications were brought down to their knees because of their internal coupling. Even though a lot of code was written as POJOs, the instantiation and configuration of those POJOs caused massive coupling, making the app brittle and hard, sometimes even impossible, to evolve. Injectors were created to concentrate that coupling (and the related initialization ordering) in one place so the rest of the code base had significantly reduced coupling. Since coupling and complexity have an exponential relation this massively reduced complexity in the application code. A reduction in complexity that more than offset the accidental complexity of the injectors (XML!). 

However. In a proper OSGi application, the problem of a big monolithic app just does not exist! A bundle that would really need Guice or Spring is almost by definition not a proper bundle. The reason is that a proper bundle is cohesive, it only contains related parts. Because it is cohesive, most of its coupling is inside and a proper bundle only exposes a tiny part of its internals with well defined OSGi ┬Áservices, either registering them or depending on them.

The consequence of this cohesion is that the complexity landscape changes. In this landscape, the accidental cost of an injector no longer weighs up to a reduction in overal complexity as it did for monoliths. This means that good old Java with the new operator works surprisingly well, inside a cohesive bundle it lost a lot of its bad side effects. So plain old Java, as James G. intended it, is actually the best for code inside a bundle. With plain old Java, the IDE is your friend again! You can navigate and refactor at will since Eclipse is aware of your complete type tree inside a bundle, nothing is hidden behind the injector. As long as an implementation class is inside your bundle, you can use it since your IDE knows all its dependencies. That is, if you want to delete it or rename it, go ahead, since all possible dependencies are inside your bundle. Therefore, an injector just creates extra boiler plate, unnecessary barriers, and isolates the type tree while no longer providing an actual benefit.

So if you feel that you need an injector inside a bundle, you should probably redesign that bundle, it is highly likely you cram unrelated parts in it.

Now, so far this was about the bundle internals. The next story is of course the external dependencies. A proper bundle consists of a set of (DS) components. Each component is configured by DS from Configuration Admin, it has its own life cycle based on its configuration and (optionally configured) dependencies. With the annotations, the overhead of using this is quite minimal. The following is a complete component that registers one service when its two service dependencies are met.

 public class FooComponent implements Foo {
  private Bar bar;
  void activate( Map map) { ... }

  void foo() {;

  void setLog( LogService log) { }

  void setBar( BarService bar) { = bar; }


The magic of these components is, is that suddenly you can make any object an active component. Once it is a component, you get configuration data for free (you can even instantiate multiple in of them under Configuration Admin control), you get full dynamic dependency management, and also service registration is for free. These OSGi service components are as fundamental a shift in computing as objects were in the nineties. Ok, maybe we could reduce this tiny amount of boilerplate (and we are working on some additional simplifications) but surely not by much.

So to summarize. I think the accidental complexity of an injector inside a cohesive bundle is not balanced by reduced overall complexity. The DS spec strikes a fine balance by using injection for the external (dynamic) dependencies but assuming normal off the shelf Java for internal code. So, for a change, try unadulterated Java inside your DS components, the new operator is actually quite handy!

Peter Kriens


Monday, September 22, 2014

Become an OSGi Certified Developer

Are you an OSGi Ninja and would like to show the world?

The OSGi Alliance is starting a developer certification program where you can become an OSGi Certified Developer. The first exam, OSGi Developer Certification - Foundation Level (DCFL), is held just before the OSGi Community Event in Ludwigsburg on Monday October 27th.
This exam covers the Core OSGi Framework R5 and an essential set of OSGi service specifications, including:
  • Declarative Services
  • Configuration Admin
  • Http Service
  • Log Service
Further exams, such as Advanced, Enterprise and Residential are planned.

If you're interested in taking part and getting your OSGi qualification, read more about it and sign up here:

Blog Archive