Things should be as simple as possible, but not simpler.
As true as this is, the boundary between simple and simplistic is unfortunately highly subjective. Never change things that work for you. It is as simple as that. However, many development organizations are not in that blissful state because they have complex problems they need to solved in an increasingly complex environment.
The value that OSGi brings to the table is when you have to maintain a large code base over long periods of time, you have many external dependencies, you need to provide middleware, if you work with multiple developers, or if your development is spread over multiple locations. For those situations OSGi provides a type safe module extension to Java that can significantly reduce your development complexity.
So what is the usability issue? You can build powerful applications with very little complexity with OSGi?
Unfortunately developing with OSGi can be really hard because both the modularity and type safety of OSGi are at odds with prevailing dynamic class loading patterns in Java. OSGi is often the messenger telling you that your baby is neither modular nor really type safe. For example, Dependency Injection in Spring requires access to implementation classes from the configuration module into the providing module, exactly the classes you should really keep private in a modular world. Worse, dynamic loading is only type safe if there is a single namespace. A single namespace is the cause of DLL hell aka JAR hell that OSGi addresses by managing multiple name spaces. The resulting mess is what causes the usability problem.
These are not OSGi problems, if Jigsaw one day will be modular and type safe it will have exactly the same issues!
To get the many benefits of modularity and type safety you must therefore change the way you think about Java ... If something is inside your module everything works as before but if you want to work with other modules you need to consider type safety and module boundaries. Object Oriented Design forced you to consider inheritance, encapsulation, and object identity, things that did not exist in Structured Design. Java modularity requires just such a paradigm shift. What we need is an inter module communication mechanism that truly hides implementation classes and enforces the type safety across modules. OSGi services are such a mechanism.
As Spring heavily relies on dynamic class loading it ran head on into the module boundaries and multiple name spaces. Though Spring DM included OSGi services the problem was that they were more supported than embraced, resulting in many Spring DM/Blueprint modules to use the existing dynamic class loading model. This results in the import/export of large numbers of implementation classes, increasing the public space, the opposite of modularity. The history would be very different if the Spring libraries had embraced services, setting an example for true modularity.
There are only two solutions to this problem: Change OSGi or change the world. As I do believe there is no value in a little bit of modularity I can only see false advertising value in punching convenient holes in the modularity story of OSGi. I do believe it is worth keep strong modularity and its enforcement. Very large applications like Eclipse, Websphere, JDeveloper, and others demonstrate that at certain scales OSGi becomes a necessity. And as more and more open source projects start to embrace OSGi it will become easier and easier to build OSGi based systems.
That said, as Rod justly points out, there are lots of people that are happy with a Tomcat based solution. Moving to OSGi when have dependencies on libraries that are hard core dynamic class loaders is then often not worth it. We're therefore thinking about a version of OSGi that inherits the class loading architecture of whatever environment it runs in; a JAR on the class path is then treated as a bundle. For example, in a WAR all entries in the WEB-INF/lib directory would be available as bundles. We tested this and it is a testament to modularity that many existing bundles actually worked out of the box. Though this solution obviously does not help when you are in JAR hell, it does provide many of the benefits of OSGi in your own familiar environment. And one day, when JAR hell finally arrives for you, the OSGi Service Platform is there to serve.
Peter Kriens