This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
blog:eclipse_way_core_values [2018/02/01 11:13] djo |
blog:eclipse_way_core_values [2018/02/01 11:37] djo [Isolate plug-ins from changes in dependencies of dependencies] |
||
---|---|---|---|
Line 17: | Line 17: | ||
Eclipse is built by multiple distributed teams numbering nearly 700 concurrent engineers (as-of the 2014 release). In order to enable this many engineers to work together without constantly breaking each others' code, Eclipse designed a plug-in system into the architecture from the beginning. | Eclipse is built by multiple distributed teams numbering nearly 700 concurrent engineers (as-of the 2014 release). In order to enable this many engineers to work together without constantly breaking each others' code, Eclipse designed a plug-in system into the architecture from the beginning. | ||
+ | |||
+ | In my experience, there are two key aspects to this plug-in system that help it to succeed as well as it has both technically and from a product-management perspective. These are: | ||
+ | |||
+ | - **Internal vs. External API:** Eclipse separates code that is intended to be consumed by other projects from internal implementation detail. Further, developers provide strong guarantees to customers that External API may be evolved, but not in a way that breaks their code. Internal APIs, on the other hand, may break, change, or be completely rewritten as needed. | ||
+ | - **Isolate plug-ins from changes in dependencies of dependencies:** Eclipse's plug-in engine sandboxes and isolates plug-ins from being able to view or change transitive dependencies of dependencies. This minimizes "version hell" caused by these transitive dependencies utilizing conflicting versions of the same library. The purpose is again to enable interdependent projects to evolve independently. | ||
+ | |||
+ | Here are a few more thoughts on each of these topics. | ||
+ | |||
+ | ==== Separate internal and external API ==== | ||
A plug-in is a Java Jar that is divided into two kinds of APIs: | A plug-in is a Java Jar that is divided into two kinds of APIs: | ||
Line 29: | Line 38: | ||
API is a deep topic and worth much more than this brief introduction. If there is demand, I can write more about that. | API is a deep topic and worth much more than this brief introduction. If there is demand, I can write more about that. | ||
+ | |||
+ | ==== Isolate plug-ins from changes in dependencies of dependencies ==== | ||
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. |
+ | |||
+ | 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. | ||
- | 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. | + | 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. |