Jecki Go wrote:When I first heard about OSGi it was with a lot of excitement, having been in Java development for several years with the fact that building a modular and easy to manage system is way difficult, at least back in the early days. Then I tried to read more about OSGi, reading through tutorials, watching some online presentation. Boy this is a very tough subject (at least it is to me). Looking at the adoption of OSGi in the industry I might say that OSGi is not mainstream yet and most probably it is not because of the steep learning curve that people like me has to deal with in order to get the first grasp of this old "new" creature. I mean the whole idea is just brilliant, but really it's not easy to grab.
Part of this is the fact that modularity itself is a hard subject. It also doesn't help that OSGi frameworks have the job of enforcing modularity, saying "no you can't do that" when you try to bend the rules

Like other development policies this can be frustrating when all you want to do is get on and write new features, but it does lead to modular solutions where you really can take a module and re-use it in other projects. The ability to hide away implementation classes also makes "shading" unnecessary (where you refactor a third-party library under a different package to avoid conflicts on the classpath).
Jecki Go wrote:1. How do you see the OSGi is going in future in terms of ease of development and industry adoption?
Definitely we need to improve tooling. We also need to improve some of the messages from OSGi frameworks so developers aren't left scratching their heads - Richard has been working on some of the constraint exception messages in Felix, which although technically correct weren't always easy to understand.
Jecki Go wrote:2. Is OSGi really going to be mainstream java modularity framework?
Right now OSGi has the advantage that it is actually being used in many real-world applications - it may not break into the mainstream itself, but I think any mainstream modularity framework would have to acknowledge the lessons learnt by OSGi and provide a way to consume bundles.
Jecki Go wrote:3. Do you think there's a good chance that OSGi will be used in a day to day basis by huge number of Java Developer in Enterprise Applications? Or will it only reside at a low level framework, library and Application Server use?
OSGi (services) + Dependency Injection is a powerful solution. That way you get the benefits of modularity and the dynamics of OSGi services without being directly tied to OSGi or its API. I think most Enterprise Java developers will end up using OSGi via something like Spring, Guice, or CDI.