| Eclipse Architecture - Plugin Registry and Initialisation [message #1716619] |
Sun, 06 December 2015 09:50  |
Eclipse User |
|
|
|
Hi, i am modeling the the architecture of eclipse in the scope of a lecture at the Vienna University of Technology. Me and my group would like to show in a sequence diagram how eclipse is initialized. Especially we would like to model the initialization of Plugins, because we focus in our analysis on the modularity of the architecture. In detail the sequence diagram contains the scenario:
- Start Eclipse
- Load Plattform/Workbench
- Initialise the Plugins installed by User with the corresponding UI Elements
We read the documentation (it is really well done). But no we find it really hard to understand how the single components play together. We would really appreciate if you could help us with the following questions:
- How are platform and workbench initialised after starting eclipse?
- What components interact with the Plugin Registry? When?
- When/how are the UI Elements loaded?
|
|
|
| Re: Eclipse Architecture - Plugin Registry and Initialisation [message #1716742 is a reply to message #1716619] |
Mon, 07 December 2015 17:26  |
| Eclipse User |
|
|
|
From the bottom up, here is what happens:
- OSGi starts
- A specific bundle called the simpleconfigurator installs all the bundles in OSGi. This bundles reads the file called configuration/o.e.e.simpleconfigurator/bundles.info which is an exhaustive list of all the bundles that need to be installed.
- OSGi raises the start levels and all teh bundles marked to be started in the bundles.info are started.
- The runtime bundle is started (because it is flagged as such). This causes the plugin registry to load all the plugin.xml files and resolve the extension to the extension points. This also causes the application to start which will then start the specified application. This could be the workbench but there is also a number of other applications (some being just command line apps like the p2 director)
- When the application starts, it is the responsibility of the plug-ins constituting the application to be load the necessary extensions (usually looking for all the extensions contributed to one extension point) and do whatever it wants with it. In the case of the IDE, this starts the workbench which reads a large number of extension points such as views, commands, editors, etc. and it builds internal representation of this information (some of this goes into the EMF model representing the layout of the workbench)
- With those models, the workbench (again composed of multiple plugins) creates a shell and a number of parts into this (like editor containers, view containers), and eventually delegate the creation of the individual views and editors to the plugin contributing those.
- To be precise, with a given view id, the workbench looks up in its internal data structure the extension that declared the view and call createExecutableExtension on it. This causes the extension registry to create a new instance and return it. With this instance the workbench can get the view to be displayed by calling the various methods that have been defined as part of the contract (all views must implement ViewPart).
This last mechanism is what is used everywhere. In fact even applications (those that I described earlier) are instantiated using the exact same pattern.
Note that I'm a bit fuzzy on the internal of the workbench but this is the general idea.
HTH
|
|
|
Powered by
FUDForum. Page generated in 0.02246 seconds
Home