Why the extension point mechanism in eclipse exists

As we all know, the Eclipse platform itself is a successful OSGi application, technically speaking, and eclipse itself is driven by the OSGi protocol (which, I think, has been heard many times ~_~). At the same time, Eclipse has made a powerful expansion of the OSGi component mechanism, known as the extension point mechanism, and support for extension points is also Equinox (Eclipse's OSGi Protocol implementation) is presented to a wide range of Eclipse developers and users. About why there is extension point this supplement, is also the topic which the Foreign Technical Forum often discusses, in this also boldly guesses one, only for everybody reference.

"Key features and applicable scenarios for OSGi"

OSGi provides us with a mechanism for developing, deploying, running, and managing components (OSGI Bundle) in a modular way, including modularity, lifecycle management, loosely coupled interactions, and so on. OSGi provides us with the technology needed for component modularity, and allows for dynamic loose-coupling interaction between modules in such a way as to provide a solid foundation for our long-awaited development of pluginable System (OSGi technology, You can take part in the OSGi protocol and some discussion on the application of OSGi in a foreign forum. In essence, OSGi does not devote much effort to focus on how to make a component more extensible and open, in the pursuit of component modularity and the need for the component itself to have a black box effect.

As we can see from the above exposition, OSGi itself is suitable for the kind of modular, dynamic management, Plug and Play component system, if applied to product software open, to build a reliable kernel is very useful, some of the successful application of OSGi include Eclipse, JBoss as, IBM WebSphere, and so on.

"Eclipse's Requirements"

Eclipse itself exists as an infrastructure platform, and its key requirements are to facilitate user expansion and to seamlessly integrate with the Eclipse platform itself. To be blunt, one component in Eclipse (Eclipse Plug-in) has a roughly two task: providing an extension implementation or declaring an extension requirement (of course, not exclusively for library Plug-ins, feature ...). ）。 We know that the technology implementation of a software product needs to be based on product requirements, and that the biggest requirement of eclipse as a software product is how to easily allow users to extend and seamlessly integrate these extensions.

If this needs to be met by Eclipse, what are the key qualities needed for a component (Eclipse plug-in)? Open, easy to expand!!!

Obviously, OSGi itself does not meet some of the key needs of eclipse (for both developers and users), but the modularity, declarative lifecycle management, lazy loading, and so on, of OSGi are desperately needed by eclipse, and naturally, OSGi is chosen as the driving protocol for the Eclipse kernel. Given the expansion and ease of integration between these two key requirements, Eclipse provides a mechanism for user extension points on Osig, an XML-descriptive way to configure the extended relationships between components, and the three core concepts involved are well-known: extension points (Extension point), Extensions (Extension) and extended registry (Extension Registry).