OSGi enRoute 1.0 – A Short Review


A month ago OSGi enRoute 1.0 was released. It promises to make OSGi development easier for new developers. I clicked through the base tutorial and checked if OSGi enRoute could help us to further improve the development of calvaDrive. My experience is summarized in this short review which makes no claim to be complete. I did not take a deep look into OSGi enRoute nor did I develop a business application using it.

What’s good in OSGi enRoute…

  • Convention over configuration: OSGi enRoute heavily depends on convention. It makes development easy when setting up a new project.
  • Fast development round-trip: Changes made in the code are directly deployed to the development environment and can be tested on-the-fly.
  • Set of nice and helping tools: OSGi enRoute utilizes a powerfull set of tools (e.g. Xray).
  • Automatic dependency resolver: Setting up an environment is very easy, as dependencies like Apache Felix are resolved automatically.


… and what’s not

  • Convention over configuration:
    • „OSGi enRoute requires that you group a number of projects in a bnd workspace. A bnd workspace is basically a directory with a cnf directory.“ – The Workspace
    • Tuned tool chain: OSGi enRoute forces you to use the tool chain OSGi enRoute defines.
    • Types of projects depend on the name of the project, e.g. project names ending with „.api“ are mapped to API projects: This might interfere with company guidelines.
  • Usage of special annotations: This annotations are part of the OSGi 6 specification. At the moment there are only a few providers of OSGi 6.
  • Automatic dependency resolver: Loss of control over your application.



OSGi enRoute was created „to make OSGi as easy as possible for developers to get started with OSGi without compromising its core values“ (OSGi enRoute) and this is exactly what it does. The convention over configuration paradigm makes it really easy to start developing small private projects. But when it comes to medium or large business applications or legacy projects, I don’t think OSGi enRoute is the tool you are looking for. In such projects you will often have your own constraints concerning project structure or naming conventions. In almost every business application you have to cope with third-party libraries or legacy code. This code will certainly not satisfy the conventions made by OSGi enRoute.

What’s your opinion? Did you take a deeper look into OSGi enRoute?

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.



This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.