User Tools

Site Tools


Dave Orme muses about agile and functional programming.

My current work emphasizes SOA applications using Scala, Kubernetes, and AWS with a React-based SPA front-end. I'm also interested in progressive web applications and developer tools.


Scala, Clojure, and FP


The Cloud

Data-First Development

Older work

Coconut Palm Software home

Donate Bitcoin:



Kubernetes, Docker, Streaming Data, Spark, Scala, Clojure, OSGi, Karaf, GCP, AWS, SQL


Everything I say here is my own opinion and not necessarily that of my employer.


The OSGi Building Block Pattern: An Invitation

Have you ever wondered why it seems so hard to come up the OSGi or RCP learning curve? Or, if you're already an OSGi expert, why beginners seem to have so much trouble “getting it”?

I believe one reason is that there is an impedance mismatch between the way OSGi applications are built and the way the Eclipse IDE works. More importantly, I believe that understanding this impedance mismatch illuminates a very fundamental architectural pattern in OSGi development that I call the OSGi Building Block pattern.

In this blog article, I will discuss the OSGi Building Block pattern in the abstract.

Next week at EclipseCon, Patrick Paulin and I will deliver real code showing how to leverage this pattern to make Eclipse RCP and server-side OSGi application development much easier (Architecture Patterns and Code Templates for Enterprise RCP Applications).

What is the OSGi/Eclipse Impedance Mismatch?

Consider this thought:

Eclipse works in terms of projects and dependencies. But no single project can fully define a production-quality OSGi application.


Let's use Eclipse RCP as an example:

An RCP developer might first use the “RCP Application with a View” wizard to create her initial RCP application. This wizard generates a single project defining a single OSGi Bundle.

Then the average beginner clicks the “Run” button to launch the platform and to see the wizard's result.

But in order to deploy the application, an RCP developer must create at least the following extra artifact(s):

  • A Product configuration

and normally for an enterprise-class project:

  • A Feature definition (for her bundle)
  • A releng project to drive either Maven/Tycho or PDEBuild.

And there is nowhere that I am aware that documents all of these steps in one place. So a beginning RCP developer may flounder for months before he realizes what the minimal ingredients are in a production-ready Eclipse RCP application.

What are the minimal OSGi/RCP ingredients?

For a Feature-based RCP product, the minimal building-block for a production-quality application can be represented by the following quad:

(Bundle+, Feature+, Product, Releng)

[The trailing plus sign signifies “one or more”, just like in a grammar.]

In other words, for production purposes, the *minimal* RCP application is:

  • One or more Bundles
  • Contained in one or more Features
  • In a Product configuration
  • Built by some sort of release engineering project (e.g.: Maven/Tycho or PDEBuild)

But Eclipse provides no wizards to create all of these things at once. Eclipse provides no refactorings to keep all of these things in sync as they change over time.

The Eclipse RCP wizard and the Eclipse IDE want us to think in projects. But OSGi wants us to think in terms of deployable bundles. Eclipse requires the OSGi (RCP, server-side) developer to keep this entire model in his head, and to manage it manually.

(I think I mentioned that we will deliver simple code illustrating all of this next week? ;-) )

What about other OSGi uses?

Wait! There's more!

The same principle applies for server-side OSGi, just with different names for the parts! For example, Virgo has the following minimal building-block:

(Bundle+, Plan+, ContainerConfig, Releng)

(Okay, I know you can deploy bundles to a WAR, but my understanding is that Plan files are the “new and approved” way to work with Virgo.)

And an OSGi bundle, deployed via P2 is the following minimal set of things:

(Bundle+, Feature+, P2RepoProject, Releng)

Viewing OSGi this way has helped me think about RCP applications much more clearly, because the number of distinct concepts I have to keep track of suddenly just went to 4.

It has also helped me understand how to design my builds in a modular way, because as Nick Boldt blogged, a build's target platform can be composed of multiple P2 repositories, which can be the result of prior builds. In other words, my build can consume its own output.

General form of the OSGi Building Block Pattern

I call this OSGi quad the “OSGi Building Block” pattern because it comes up frequently in one form or another in nearly all flavors of OSGi software development. The general form can be described as:

(Bundle+, Packaging+, Deployment, Release engineering)

I believe there are two powerful ramifications to this:

  1. Having standard names for things helps us to talk and reason about them. Understanding the OSGi Building Block pattern is the key to making OSGi (in all its forms) simple and easy.
  2. Direct tool support for the OSGi Building Block pattern: Maven archetypes, IDE wizards, and IDE refactorings would all be beneficial. Ultimately, these things will help to drive OSGi's TCO down and drive OSGi as an enterprise standard.

Invitation to the community

Following this second point, I would like to issue the following challenge and invitation to the OSGi community:

  • When things represent the same idea, let's try to standardize the terms we use to describe them. For example, I propose that we use the term “Packaging” to describe the singular concept represented by both a Plan and a Feature. But as the experts, does that make sense to you?
  • Since developers deal with OSGi applications in terms of repeating instances of this minimal quad, let's give them IDE tooling to let them deal with each instance of this quad as a discrete unit.

Invitation to BoF

To facilitate these discussions, I would like to invite all of the OSGi stakeholders to a BoF session this coming week at EclipseCon.

I think that OSGi's future is bright, and I think that by driving concrete plans to improve developers' lives using the OSGi Building Block pattern, we can help.

(And one final plug for Patrick and my session next week:)

If you're wondering why and how this makes OSGi development simple, come to our tutorial next week at EclipseCon: Architecture Patterns and Code Templates for Enterprise RCP Applications. Next week Patrick Paulin and I will make all of these abstract ideas concrete with real code you can take with you and use as the basis for your next project.


blog/the_osgi_and_rcp_impedance_mismatch.txt · Last modified: 2014/10/17 22:08 (external edit)