Reasons for the existence of the extension point mechanism in eclipse

As we all know, the eclipse platform itself is a successful osgi application. Technically, eclipse itself is driven by the osgi protocol (I think, you have heard this sentence many times ~ _~). At the same time, eclipse has made a strong extension to the osgi component mechanism, which is also known as the extension point mechanism, support for extension points is also presented to a wide range of eclipse developers and users as part of equinox (osgi Implementation of eclipse. The addition of the extension points is also a topic that is frequently discussed in foreign technical forums. It is also a bit of speculation here for your reference only.

「 Key features and application scenarios of osgi 」

Osgi provides us with a mechanism that pursues modularization to develop, deploy, run, and manage osgi bundle, its main technical features include modularization, lifecycle management, and loose coupling interaction. Osgi provides us with the technology required for component modularization, and allows dynamic loose coupling interaction between modules through services, this laid a solid foundation for the long-awaited pluginable System (osgi technologies can be used in osgi protocols and some discussions on osgi specific applications in foreign forums ). Essentially, osgi is pursuing component modularization and hopes that the components themselves will have a black box effect. It has not invested a lot of energy to focus on how to make a component easier to expand and more open.

Through the above description, we can see that osgi is applicable to the modular, dynamic management, and plug-and-play componentized system. If it is applied to the openness of product software, it is very useful for building a reliable kernel. Some successful osgi applications include eclipse, JBoss as, and IBM WebSphere.

「 Eclipse requirements 」

Eclipse itself is a basic platform. Its key requirement is to facilitate user expansion and facilitate seamless integration with the eclipse platform. To put it bluntly, the task of an eclipse component (Eclipse plug-in) is roughly two: provide extension implementation or declare expansion requirements (Of course, not all for library plug-ins, feature ...). We know that the technical implementation of a software product must be based on the product requirements. The biggest requirement of eclipse as a software product is how to easily allow users to expand and seamlessly integrate these extensions.

To meet the requirements of Eclipse, what are the key characteristics of an Eclipse plug-in component? Open and scalable !!!

Obviously, osgi itself cannot meet some of the key requirements of eclipse (for developers and users ), however, osgi's modularization, declarative cycle management, and lazy loading mechanisms are all urgently needed by eclipse. Naturally, osgi is chosen as the driving protocol of the eclipse kernel. Considering the two key requirements of extension and seamless integration, eclipse provides an extension point mechanism for users on top of osig to configure the extension relationship between components in XML format, the three core concepts involved are well-known: Extension point, extension, and extension
Registry ).

「 Instance discussion 」

Some abstract things are mentioned above. The following is a rough description with several examples.

First, we will discuss a theoretical example. Suppose we have two osgi bundle in the current system and then add the third strange bundle, then this new bundle cannot be automatically discovered (self-invented ~ _~), Unless the call is displayed. If the current system has a plug-in, it declares a host plug-in, and then introduces a new plug-in, the extension contract defined by host plug-in provides the extension (extesion plug-in), so this new plug-in can be automatically discovered, host
Plug-in can use eclipse to expand the Registry to find the corresponding extension, while avoiding the Close coupling between the two plug-in (note: some people think that the extension plug-in and host plug-in are tightly coupled. I think it is more appropriate to say that plug-in is developed ).

We know that the architecture of eclipse is: micro kernel, core plug-ins, and application plug-ins ).

Runtime, workbench, and resource are the so-called core plug-ins of eclipse. jdt provides extensions and seamless integration based on these core plug-ins. It also defines some extensions, it can be used by jdt itself or other extensions for seamless integration.

For general eclipse tool users, if there is no extension point mechanism, can users easily install third-party tools (essentially integrated) into eclipse? Are you concerned about some technical details?

Summary 」

As mentioned above, Eclipse plug-in is pursuing openness and expansion on the basis of osgi bundle. In fact, in terms of technology, eclipse complements the osgi protocol in the interaction between plug-ins, and the extension and extension points have become the most important interaction mode between plug-ins in the Eclipse plug-in development process, however, the loosely coupled interaction (osgi Service) between components defined in osgi is not very useful (for users ). Here, we may have a question: why is the eclipse extension point mechanism so good that it is not added to the osgi protocol? Different requirements.

Finally, let's review that eclipse provides an extension mechanism, which is essentially dependent on some of the key requirements of Eclipse: expansion and integration. The osgi protocol itself is especially used in application scenarios. The eclipse extension mechanism is a powerful supplement to the requirements of eclipse over osgi.

 

PS: This is a reprinted article. If the author has the copyright, I will delete it immediately.