OSGiConvergence

Introduction

Impala is a module based system which has it's own runtime environment. For many reasons, it is desirable not to force developers to adopt OSGi to use Impala.

However, OSGi has an attractive runtime model which is increasingly gaining traction in the Java community, and in a number of ways aligns closely with what Impala is trying to achieve. It therefore makes sense to pursue a strategy of moving towards OSGi compliance, and ultimately, allow OSGi to be leveraged as an alternative runtime for Impala applications.

Stage 1: OSGi compliance

The first stage of convergence aim to make Impala OSGi compliant, not as a functioning framework, but in a static sense:

• all features that are possible without OSGi support should still be available as before without requiring an OSGi runtime environment.
• where possible, implementations should be OSGi compatible. In other words, it should be possible to drop Impala into an OSGi environment. The Impala jars should contain the necessary metadata to allow Impala jars to be loaded as OSGi bundles. If the necessary dependent jars are present, it should be possible to install and resolve all the Impala jars.

This stage should be reached prior to the release of version 1.0.

Stage 2: OSGi as an alternative runtime

The goal here should be to combine the easy testability of Impala with deployment in an OSGi runtime. The latter should be optional. Non-OSGi based deployment should always be an option. The idea is to narrow the difference as much as possible, so that:

• as many as possible of the features that would be available in an OSGi environment are still available in a non-OSGi environment.
• deployment to an OSGi environment results in as little as possible extra burden and overhead compared to deployment in a non-OSGi environment.
  The idea is to still provide the productivity benefits of the standard Java environment even for applications which are targeted towards OSGi.

Deployment in an OSGi environment will involve restrictions not present in a standard Java environment. The idea is that these restrictions will be clearly identified, and as much as possible can be eliminated through applying the appropriate conventions when writing standard Java applications.

This stage of OSGi convergence is likely to be reached post 1.0 final.