OSGi is a successful technology for creating lightweight containers; pretty much every application server is now based on OSGi (e.g. JBoss and GlassFish) along with the commercial containers.
On the Apache ServiceMix project we found that adopting OSGi provided a much more powerful and flexible infrastructure for building application containers and lead to the creation of the Apache Karaf project as we found we'd created a powerful application container on top of OSGi.
The OSGi framework itself is great; its small, modular, powerful and extensible. In may ways its the ideal general purpose container for the Java platform.
OSGi provides an elegant & extensible framework for dealing with deployment units, lifecycles and dependencies. Its a standard adopted by various projects (Apache Felix, Eclipse Equinox, the Eclipse IDE, Apache Karaf, Apache ServiceMix, JBoss, GlassFish etc).
OSGi lets you create very modular applications which can have services and deployment units redeployed at runtime, along with supporting flexible and powerful class loader trees so that multiple versions of the same library can be shared across many deployment units in the same JVM.
Also lots of our customers love OSGi! :)
The big issue application developers hit when creating OSGi bundles is the creation, maintenance & fixing of the OSGi metadata required to use the class loader in OSGi.
Valid OSGi bundles use package level metadata, describing what packages are imported and exported along with version information (and other things like requiring explicit bundles or adding embedded jars into the bundle classpath).
Its the package level metadata thats the pain when developing applications for OSGi. While for developers of middleware containers and frameworks its fine as the underlying mechanism; it just feels too low level and fine grained for application developers to work with.
In many ways OSGi today is a little like EJB 1.0 was; EJB 1.0 provided all the features folks wanted at the time (remoting, transactions etc); the problem was there was too much explicit code & configuration. Sometimes stuff was transacted or remote; the problem was everyone had to pay the cost of these features & code bloat whether they were used or not & led to the creation of lots of cruft to get anything done.
In the EJB 1.0 days just like in OSGi today folks often say 'ah thats just a tooling problem!'. There are various tools out there to help for sure such as Felix Maven Bundle Plugin, BND, Bndtools or the MANIFEST.MF editor in Eclipse. However we think we can do better.
However we'd rather simplify application developers life so they can instead focus on simpler more coarse grained dependencies; using the transitive dependency model of Maven and similar build tools.
From an application developer perspective we'd like building applications to be pretty similar whether the deployment container is a web container like Apache Tomcat or Jetty or its an OSGi based container like Fuse ESB, Apache Karaf or Apache ServiceMix.
So we'd prefer application developers just focus on the course grained high level transitive dependency structure they already use in their existing build tools for both web apps and OSGi then let Fuse Bundles do the work of integrating into OSGi.
META-INF/maven/groupId/artifactId/pom.xml (and pom.properties file)
which contain the transitive dependency information for the jar.
So if you are already using a suitable build tool like Apache Maven then you don't have to particularly learn anything new or change your build system. You can just deploy your FABs directly into a suitable container like Fuse ESB.
This means application developers don't have different class loader mechanisms to work with; they can work with their build tool, IDE (e.g. Maven integration in IDEA / eclipse) and then just deploy it into their container (either web applications or OSGi).
Fuse Bundles then provide a simple transitive dependency class loader model; that many developers are already using and works in build tools, IDEs, web applications and now in OSGi containers - while at the same time being able to take advantage of all the features of OSGi like modularity, sharing of different versions of libraries across deployment units and hot redeployment.