The article makes OSGi look like the inventor of encapsulation and interfaces, but those concepts existed way before OSGi (from Smalltalk to frameworks like COR

The article makes OSGi look like the inventor of encapsulation and interfaces, but those concepts existed way before OSGi (from Smalltalk to frameworks like CORBA). What OSGi produced is a model to handle dependencies, service lifecycle, and provisioning. But in the Java ecosystem, those features were replaced with a mix and match of smaller projects, that are easier to adopt and use. Instead of adapting to the community, OSGi frameworks like Eclipse Equinox live on their own island. Take for example provisioning: Equinox has its own framework called P2. You don't need P2 to use OSGi. But, it's the way of doing things in Equinox. So to share a library, you need to provide packages using a P2 update site. There is no easy way of using Maven Repos [1]. The end result: tons of unnecessary complexity, and more isolation of projects that relies on Equinox tooling [2]. [1]: Tycho is the solution for interacting with Maven repos; but is not easy to setup...and in the end all the trouble doesn't pay: you end with a mix of dependency definitions that is hard to maintain/troubleshoot. [2]: I'm looking at you SWT... you promise a nice native UIs, but consuming SWTs JARs from a non-Equinox project is a pain... thank you P2 and OSGi! :)