In addition to allowing plug-in jars to declare what packages are APIs, the Eclipse container allows plug-ins to declare their dependencies similar to the way Maven projects declare dependencies. ​And the container enforces these dependencies at run-time.

+

In addition to allowing plug-in jars to declare what packages are APIs, the Eclipse container allows plug-ins to declare their dependencies similar to the way Maven projects declare dependencies. ​

-

What does this mean? It means that OSGi sandboxes each plug-in with its own classpath. ​ In addition, ​a given plug-in's classpath is isolated ​to just the libraries that a plug-in depends on, and not dependencies of dependencies. ​Since plug-ins do not see transitive dependencies among each other, this minimizes conflicts caused by dependencies of dependencies depending on differing versions of the same library and enables plug-ins to be evolved ​independently of each other by multiple teams around the world.

+

And the container enforces ​that a given plug-in ​jar only has access ​to the exact libraries/​versions ​that it declares as dependencies, and **not** any transitive ​dependencies of dependencies.

+

+

Since plug-ins do not see transitive dependencies among each other, this minimizes conflicts caused by dependencies of dependencies depending on differing versions of the same library and enables plug-ins to evolve ​independently of each other by multiple teams around the world.

While this approach doesn'​t solve every problem related to "jar version hell", it goes a long way toward keeping differing teams from breaking each others'​ code when they change their dependencies or dependencies'​ versions.

While this approach doesn'​t solve every problem related to "jar version hell", it goes a long way toward keeping differing teams from breaking each others'​ code when they change their dependencies or dependencies'​ versions.