OSGi is much like a religion. I’ve even come up with the ten commandments of OSGi:
1. the OSGi way is the only way
2. all 3rd party code that you touch must be OSGi compliant
3. everything must be an OSGi bundle
4. every bundle must have a public part (api)
5. every bundle must keep its private parts covered
6. thou may not rely on the start order of your bundles
7. thou may not rely on a service being present
8. other bundles may be loaded and unloaded at any time
9. thou shall use OSGi in every project
10. thou shall bring the ways of OSGi upon the non-believers
Okay, it’s a bit of a stretch, I admit it. What I’m saying though about it being like a religion, is that it demands of you to follow certain rules. But if you look around you, very few people actually follow them. And if you try to follow them, you’ll find it very difficult.
Why is that? You can do your project the OSGi way, but you will use 3rd party code. Which may or may not be OSGi compliant. If it’s not, you’ll have to bundle it yourself. You can use bnd to do so automatically, but that doesn’t always work, especially for larger projects with lots of dependencies. So sooner or later you’ll find yourself spending 1-2 days trying to coerce some library into OSGi form. With maven it would be a 30 second job, but you’re doing OSGi so you’re stuck with that.
That begs the question: why do OSGi? It was initially conceived for embedded systems, which needed 100% uptime and the possibility of updating modules independently of one another, without stopping the system. Is your project about that? Then you have a valid case for OSGi. You aren’t likely to run into the problems I mentioned, since you’ll likely restrict your use of 3rd party code for reasons of size and performance.
However, most of us work on plain old Java applications. Is modularity good? Well yes! Do you need to update modules without restarting the application? No, you don’t. Do you replace service implementations at runtime? No, you don’t. Do you load and unload modules dynamically at runtime? No, you don’t.
That means for most projects the only gain is modularity, for which you pay a hefty price in the complexity of managing dependencies. There are simpler ways to ensure proper modularization.
Some web applications will need to update without downtime, but for those OSGi is not the answer either. If you need high availability, you’ll already have a cluster or a bunch of servers behind a load-balancer, which you can update without taking the application down.
Conclusion: OSGi is good for what it was originally intended for, but a real pain for most other projects.