This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | |||
blog:eclipse_way_core_values [2018/02/01 11:33] djo [The Eclipse Modularity Story] |
blog:eclipse_way_core_values [2018/02/01 11:37] (current) djo [Isolate plug-ins from changes in dependencies of dependencies] |
||
---|---|---|---|
Line 43: | Line 43: | ||
In Eclipse, plug-ins run inside Eclipse's OSGi container. OSGi adds an additional benefit to Eclipse's plug-in and API story: | In Eclipse, plug-ins run inside Eclipse's OSGi container. OSGi adds an additional benefit to Eclipse's plug-in and API story: | ||
- | 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. |