Learn how Eclipse plug-ins use osgi

Most Java programming language developers recognize eclipse through ide functions. Eclipse IDE is actually calledPlug-insSet of interactive components. These plug-ins form the foundation of the IDE and can be used to create other desktop applications. The minimum plug-in set required to create an eclipse-based application is calledEclipse rich client platform(RCP ). However, the plug-in itself cannot be started. They must be enabled and operated in an environment. Eclipse uses the implementation of osgi R4 specifications to provide the environment.

Because eclipse is essentially driven by osgi, you must understand the relationship between the concept of Eclipse plug-in and the osgi framework. In this article, I will explain this relationship in detail by describing what plug-ins are for the eclipse platform. Next, we will describe the development of plug-ins in the implementation of osgi from the eclipse V2.1 platform to today. Finally, we will introduce in detail the manifest. MF option provided by osgi for Eclipse plug-ins.

What is a plug-in?

Eclipse online help defines the plug-in:

"Plug-ins are structured packages of code and/or data that provide functions for the system. Functions can be provided in the form of code libraries (Java classes with public [application interfaces] APIs), platform extensions, and even documents. Plug-ins can define extension points and well-defined locations. Other plug-ins can add features in these locations ."

One important thing to note is that plug-ins provide functions in a structured manner. They can provide services (such as logs) or functions that can be used in the user interface (UI), such as editors. All plug-ins are defined in the same structured manner regardless of the function.

Back to Top

To osgi Development

As mentioned above, eclipse uses osgi as the basis of the plug-in system. But not always. Earlier versions of eclipse are also designed as a collection of plug-ins, and eclipse includes its own dedicated plug-in system to manage interaction. However, as Eclipse IDE requirements grow, a stronger solution is required. The basic requirements of this new system include the ability to dynamically add new plug-ins and stop existing plug-ins. After a lot of research, the eclipse Creator decided to implement osgi framework specifications to replace the dedicated plug-in framework.

Osgi is the specification of the service platform. Eclipse provides one of the many available implementations of this specification and serves as a reference for the latest osgi R4 specification. Osgi is a Java-based framework designed for systems that require long runtime, dynamic updates, and minimal damage to the running environment. Originally, osgi was intended for home automation and home gateway devices. Recently, traces of mobile phones and cars have been found.

At the core, osgi is a component and service model, as shown in 1. The osgi Specification definesBind packageModular unit. (Unless otherwise specified, eclipse terminologyPlug-insAnd osgi termsBind packageIt can be used in exchange because all Eclipse plug-ins are now osgi binding packages .) Osgi also provides Java Virtual Machine (JVM)-level service registration. This binding package can be used for publishing, discovering, and binding to services.

Figure 1. Interaction between the host operating system, Java, and osgi Layers

The osgi Specification defines the infrastructure for the lifecycle of a bound package and the Interaction Mode of the bound package. These rules are enforced by using a special Java class loader. In Java applications, all classes in classpath are visible to all other classes. Instead, the osgi Class Loader restricts Class Interaction Based on the options specified in the osgi specification and the manifest. MF file of each bound package (which will be detailed later.

Eclipse IDE uses an osgi subset around modularity and bound package lifecycle. However, it uses the service support provided by osgi to the minimum. Instead, eclipse provides its own extension point system to enable binding package interaction. Bind the package to expose the function to other extensions. The binding package also defines its own extension points, allowing other binding packages to contribute to them. An example of using the extension points in eclipse is the preferences window. The core Eclipse plug-in provides a central window and exposes extension points to allow contributions to other preference pages. When plug-ins are added to eclipse, they can contribute their own pages. The extension point model in eclipse is different from the basic osgi service. The bound package extension points are owned by the defined binding package. Other binding packages only contribute to these points. Instead, any bound package can implement and use the osgi service.

Back to Top

Use osgi to implement eclipse

In eclipse versions earlier than 3.1, plug-in dependencies and extensions are defined in the plugin. xml file of each plug-in. In the new version of eclipse using osgi, the dependency information is decomposed into the manifest. MF file, while the plugin. xml file only contains the XML definition of the extension and extension points. It is very useful to see a vivid working example that demonstrates this development. Listing 1 shows the code snippet of the org. Eclipse. PVDF. UI plug-in eclipse V3.0.

Listing 1. code snippet in org. Eclipse. PVDF plug-in

<?xml version="1.0" encoding="UTF-8"?><?eclipse version="3.0"?><plugin id="org.eclipse.pde.ui" name="%name" version="3.0.2" provider-name="%provider-name" class="org.eclipse.pde.internal.ui.PDEPlugin"> <runtime> <library name="pdeui.jar"> <export name="*"/> </library> </runtime> <requires> <import plugin="org.eclipse.core.runtime.compatibility"/> <import plugin="org.eclipse.ui.ide"/> <import plugin="org.eclipse.ui.views"/> <import plugin="org.eclipse.jface.text"/> <import plugin="org.eclipse.ui.workbench.texteditor"/> <import plugin="org.eclipse.ui.editors"/> <import plugin="org.eclipse.ant.core"/> <import plugin="org.eclipse.core.resources"/> <import plugin="org.eclipse.debug.core"/> <import plugin="org.eclipse.debug.ui"/> <import plugin="org.eclipse.help.base"/> <import plugin="org.eclipse.jdt.core"/> <import plugin="org.eclipse.jdt.debug.ui"/> <import plugin="org.eclipse.jdt.launching"/> <import plugin="org.eclipse.jdt.ui"/> <import plugin="org.eclipse.pde"/> <import plugin="org.eclipse.pde.build"/> <import plugin="org.eclipse.search"/> <import plugin="org.eclipse.team.core"/> <import plugin="org.eclipse.ui"/> <import plugin="org.eclipse.update.core"/> <import plugin="org.eclipse.ui.forms"/> <import plugin="org.eclipse.ant.ui"/> <import plugin="org.eclipse.jdt.junit"/> <import plugin="org.eclipse.ui.intro"/> <import plugin="org.eclipse.ui.cheatsheets"/> </requires><!-- Extension points --> <extension-point id="pluginContent" name="%expoint.pluginContent.name" schema="schema/pluginContent.exsd"/> <extension-point id="newExtension" name="%expoint.newExtension.name" schema="schema/newExtension.exsd"/><extension-point id="templates" name="%expoint.templates.name" schema="schema/templates.exsd"/><extension-point id="samples" name="%expoint.samples.name" schema="schema/samples.exsd"/><!-- Extensions --> <extension point="org.eclipse.ui.perspectives"> <perspective name="%perspective.name" icon="icons/eview16/plugins.gif" class="org.eclipse.pde.internal.ui.PDEPerspective" id="org.eclipse.pde.ui.PDEPerspective"> </perspective> </extension>

 

<export name="*"/>The Declaration exposes all packages in the plug-in for use by other plug-ins. The plug-in dependency import section lists the required plug-ins for the org. Eclipse. PVDF. UI plug-ins.

The following two sections Define the extensions that org. Eclipse. PVDF. UI can be used for other plug-ins and their contributions to other plug-ins. In this example, you can see the definition of the custom Eclipse plug-in Development Environment (PVDF) view.

Let's take a look at the same plug-in definition in eclipse v3.1. Listing 2 shows the plugin. xml file.

Listing 2. plugin. xml

<?xml version="1.0" encoding="UTF-8"?><?eclipse version="3.0"?><plugin> <!-- Extension points --> <extension-point id="pluginContent" name="%expoint.pluginContent.name" schema="schema/pluginContent.exsd"/> <extension-point id="newExtension" name="%expoint.newExtension.name" schema="schema/newExtension.exsd"/> <extension-point id="templates" name="%expoint.templates.name" schema="schema/templates.exsd"/> <extension-point id="samples" name="%expoint.samples.name" schema="schema/samples.exsd"/><!-- Extensions --> <extension point="org.eclipse.ui.perspectives"> <perspective name="%perspective.name" icon="icons/eview16/plugins.gif" class="org.eclipse.pde.internal.ui.PDEPerspective" id="org.eclipse.pde.ui.PDEPerspective"> </perspective>

 

Note that the export and import information is missing. This information is now in the manifest. MF file shown in listing 3.

Listing 3. manifest. MF

Manifest-Version: 1.0Bundle-Name: %nameBundle-SymbolicName: org.eclipse.pde.ui; singleton:=trueBundle-Version: 3.1.0Bundle-ClassPath: org.eclipse.pde.ui_3.1.0.jarBundle-Activator: org.eclipse.pde.internal.ui.PDEPluginBundle-Vendor: %provider-nameBundle-Localization: pluginRequire-Bundle: org.eclipse.core.runtime, org.eclipse.ui.ide, org.eclipse.ui.views, org.eclipse.jface.text, org.eclipse.ui.workbench.texteditor, org.eclipse.ui.editors, org.eclipse.ant.core, org.eclipse.core.resources, org.eclipse.debug.core, org.eclipse.debug.ui, org.eclipse.jdt.core, org.eclipse.jdt.debug.ui, org.eclipse.jdt.launching, org.eclipse.jdt.ui, org.eclipse.pde, org.eclipse.pde.build, org.eclipse.search, org.eclipse.team.core, org.eclipse.ui, org.eclipse.update.core, org.eclipse.ui.forms, org.eclipse.ant.ui, org.eclipse.jdt.junit, org.eclipse.ui.intro, org.eclipse.ui.cheatsheets, org.eclipse.update.configurator, org.eclipse.help.baseBundle-ManifestVersion: 2Eclipse-AutoStart: trueExport-Package: org.eclipse.pde.internal.ui;x-internal:=true, org.eclipse.pde.internal.ui.build;x-internal:=true, . . . org.eclipse.pde.ui, org.eclipse.pde.ui.internal.samples;x-internal:=true, org.eclipse.pde.ui.templates

 

Various plug-ins are now specified as required bind packages. * The package export has been replaced with the list of explicitly exported packages.

The dependency at the plug-in level needs to be explicitly exported and imported into the package. When eclipse announced this message, it caused a lot of turmoil. The main complaint is the lack<export name="*"/>. However, this province has many reasons. The most important reason is the speed gains from explicit import and export. In earlier versions of Eclipse, you must open and browse Each plug-in JAR file to determine which classes it contains. Excluding * export, it also provides a level-1 protection to prevent plug-ins from exposing unnecessary classes. Plug-in developers must make specific choices to make plug-in functions available for external use. This restriction allows internal packages to be retained internally.

Back to Top

Osgi list options

The core draft of the osgi R4 framework currently has almost 300 pages in pdf format. Each part of the introduction to this specification is beyond the scope of this article, but I will discuss the osgi manifest. MF option that Eclipse plug-in developers are particularly interested in:

Bundle-Activator

This class is used to start and stop binding packages. In the preceding example org.eclipse.pde.internal.ui.PDEPluginClass. This type of extension org.eclipse.core.runtime.Plugin, Implemented BundleActivatorInterface.

Bundle-ClassPath

This attribute specifies the classpath to be used to bind the package. This attribute can contain references to the directory or jar file in the jar file of the bound package. You can use a period to specify the root of the bound package. In the example eclipse pdpd Bind package, specify org. Eclipse. PVDF. ui_3.1.0.jar in the jar file of the BIND package. If you import the source version of the plug-in to the workspace, the import process changes the classpath package to display Bundle-ClassPath:This allows the development version of the plug-in to select the compiled Bind package class.

Bundle-Version

This attribute specifies the version number of the bound package. The package import and necessary package binding specifications can include the version number of the bound package.

Export-Package

This attribute specifies all packages to be publicly exposed to other plug-ins.

Import-Package

This attribute specifies all packages to be explicitly imported from the required plug-in. By default, all packages must be resolved for the Bind package to be started. You can also import a package as an option to support the case where the package does not exist. The explicitly imported class is parsed before the package in the require-bundle plug-in.

Require-Bundle

This attribute specifies the Bind package to be imported into and the exported package in the given Bind package. The specified Bind package is parsed after the explicit package is imported.

Other configuration options provided by ECLIPSE

Partner Class Loader options

First, create a plug-in for hibernate. Create a plug-in that contains the domain-specific class that is dependent on hibernate. Add the following lines to the hibernate plug-in list:Eclipse-BuddyPolicy: registered.

Add the following configuration attributes to the ins list that contain domain-specific classes or resources: Eclipse-RegisterBuddy: hibernate.

This row allows the plug-in to expose itself to the hibernate plug-in through declaration, which is unknown in advance. Now, the hibernate plug-in can see the required classes, although it does not specifically import them.

The manifest. MF configuration options included in the osgi specification do not provide all the functions required by the eclipse platform. Therefore, the eclipse creator has added multiple extensions (we recommend that you include them in future osgi specifications ):

Export-PackageHeader Extension

Eclipse has two osgi parser methods -- defaultAnd strict, You can use osgi.resolverAttribute. Eclipse also includes Export-PackageTwo extensions of attributes -- x-internalAnd x-friendsWhen the strict mode is enabled, these two extensions are enforced.

x-internal

The default value of this attribute is False. When this option is used to specify the internal package TrueEclipse pdns are not allowed to be used.

x-friends

This option is similar x-internal, But allow the specified bound package to use the exported package with this option. Other binding packages are prohibited. x-internalThe option takes precedence over x-friends.

Eclipse-AutoStart

By default, eclipse loads the bound package as needed. Therefore, when the Bind package of the first class included in the imported Bind package requires this class, the BIND packages will be loaded. Specify this value ??This will cause eclipse to load the bound package at startup. You can also specify the exception list. They are classes and resources that can be loaded without starting the BIND packages containing them.

Eclipse-PlatformFilter

This attribute allows you to specify a value equal to or greater True. The following information can be included in the specified expression:

• osgi.nl, Indicating the language
• osgi.osIndicates the Operating System
• osgi.arch, Indicating the architecture
• osgi.ws, Indicating the Window System

An example of how to use this property is as follows:SWT_AWTVerify whether the OS is Mac OS X. (Standard Widget Toolkit (SWT) Mac OS X currently does not support this function .)

Eclipse-BuddyPolicy

This option specifies the class for loading the bound package policy. Generally, a binding package is visible only in its internal class and the internal class imported from the dependency binding package. Hibernate is a popular example used in the eclipse news group to explain the partner class loading. The Hibernate framework must view the classes and resources created by the user rather than part of hibernate. In this case, when the project is used to dynamically populate the class from the Hibernate query language (hql) query. By default, Hibernate cannot view the classes outside the plug-in that contains the hibernate JAR file. Instead, you need to modify the hibernate plug-in to create each plug-in that contains the unacceptable classes of the hibernate map. Fortunately, the partner Class Loader option described in the partner Class Loader option section solves this problem.

Back to Top

Future trends of eclipse and osgi

Eclipse has benefited a lot from using osgi and gained a robust system for dynamically managing component lifecycles. New methods of use are explored every day, such as server-layer feature servlet, JavaServer pages, and other HTTP resources in the eclipse style plug-in.

The eclipse Foundation has decided to play a key role in driving osgi specifications forward so that you and others can use osgi. Many osgi specifications were added during the transition from a dedicated Eclipse plug-in framework to osgi, which were added as part of the osgi R4 specification release. Therefore, the eclipse equinox project has become an evolving osgi reference implementation. This implementation and the creation of Java specification request (JSR) 291 for managing and developing osgi ensures that the eclipse/osgi partnership will continue to succeed in the next few years.

 

[Eclipse plug-in] org. Eclipse. UI. Activities usage