Learn how the Eclipse plug-in uses OSGi

September 21, 2006 the core of the Eclipse Integrated Development Environment (IDE) and Eclipse Rich-Client Platform (RCP) applications is implemented by the Open Services Gateway Initiative (OSGI) specification Driven. This article illustrates the relationship between Eclipse and OSGi by describing what Plug-ins are for the Eclipse platform and tracking the development of Plug-ins from Eclipse V2.1 to today's OSGi based implementations. It also explains the OSGi manifest.mf file option and the additions provided through Eclipse.

Most Java™ programming language developers understand Eclipse through the functionality of the IDE. The Eclipse IDE actually consists of a collection of interactive components called Plug-ins. These plug-ins form the foundation of the IDE, and they can also be used to create other desktop applications. The minimum set of plug-ins required to create an eclipse based application is called the Eclipse Rich Client Platform (RCP). However, the plug-in itself cannot be started. They need to be started and manipulated in an environment. Eclipse provides the environment with an implementation of the OSGi R4 specification.

Because Eclipse is essentially OSGi-driven, you must understand how the concept of the Eclipse plug-in relates to the OSGi framework. In this article, I'll explain this relationship in detail by describing what Plug-ins are for the Eclipse platform. It then describes the development of Plug-ins in the Eclipse V2.1 platform to today's OSGi based implementations. Finally, the MANIFEST.MF options that are provided by OSGi that are applied to the Eclipse plug-in are described in detail.

what the plugin is.

The Eclipse online Help defines a plug-in as: "A plug-in is a structured package of code and/or data that provides functionality for the system." Functionality can be provided in the form of a code base (a Java class with a common [application interface] API), a platform extension, or even a document. Plug-ins can define extension points, well-defined locations, and other plug-ins can add functionality in these locations. ”

One important point to note is that Plug-ins provide functionality in a structured way. They can provide services (such as logs) or functions that can be used in the user interface (UI), such as editors. Regardless of the functionality, all plug-ins are defined in the same structured fashion.

to the development of OSGi

As mentioned earlier, Eclipse uses OSGi as the basis for a plug-in system. But this is not always the case. Earlier versions of Eclipse were also designed as a collection of Plug-ins, and Eclipse included its own dedicated plug-in system to manage interactions. However, with the growth required by the Eclipse IDE, a stronger solution must be needed. 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 replace the dedicated plug-in framework by implementing the OSGI Framework specification.

OSGi is the specification of a service platform. Eclipse provides one of the many available implementations of the specification and is used as a reference implementation for the latest OSGi R4 specification. OSGi is a java-based framework designed for systems that require long running times, dynamic updates, and minimal disruption to the running environment. Initially, OSGi was designed for home automation and home gateway devices. Recently, it has been spotted from mobile phones to cars.

At the core, OSGi is a component and service model, as shown in Figure 1. The OSGI specification defines a modular unit called a binding package. (in the following article, unless specifically specified, the Eclipse term plug-in and the OSGi term bundle are interchangeable, because all eclipse plug-ins are now OSGi bundles.) OSGi also provides a Java Virtual Machine (JVM)-level service registry that can be used to publish, discover, and bind to services.
Figure 1. Interaction between host operating systems, Java, and the OSGi middle tier

The OSGi specification defines how the underlying schema of the bundle's lifecycle and how it interacts with the bundle. These rules are enforced by using a special Java class loader. In a generic Java application, all classes in CLASSPATH are visible to all other classes. Instead, the OSGi class loader restricts class interaction based on the OSGi specification and the options specified in the MANIFEST.MF file for each bundle (described later in detail).

The Eclipse IDE uses an OSGi subset that surrounds the lifecycle of modularity and binding packages. However, it uses at least the service support that OSGi provides. Instead, Eclipse provides its own extension point system to enable binding package interaction. The binding package exposes functionality to other extensions. The bundle also defines its own extension point, allowing other binding packages to contribute functionality to it. An example of using an extension point in Eclipse is the Preferences window. The core Eclipse plug-in provides a central window and exposes extension points to allow contributions from other preference pages. When Plug-ins are added to Eclipse, they can contribute their own pages. The model of an extension point in Eclipse is different from the basic OSGi service. The bundle extension points are owned by the definition bundle, and other bindings only contribute to those points. Instead, any bundle can implement and use OSGi services.

implementing Eclipse with OSGi

In previous 3.1 versions of Eclipse, the plug-in dependencies and extension and extension points were defined in the Plugin.xml file for each plug-in. In a new version of Eclipse using OSGi, dependency information is decomposed into MANIFEST.MF files, while plugin.xml files contain only XML definitions of extension and extension points. It is useful to look at a lively work example that demonstrates this development. Listing 1 shows the code snippet for the Org.eclipse.pde.ui plug-in in Eclipse V3.0.
Code Snippets in Listing 1. Org.eclipse.pde plug-ins

<?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> </runti me> <requires> <import plugin= "org.eclipse.core.runtime.compatibility"/> <import plugin= " Org.eclipse.ui.ide "/> <import plugin= org.eclipse.ui.views"/> <import "plugin=" XT "/> <import plugin=" org.eclipse.ui.workbench.texteditor/> <import "plugin=" S "/> <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 Gin= "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 gin= "Org.eclipse.pde"/> <import plugin= "Org.eclipse.pde.build"/> <import plugin= "Org.eclipse.searc" H "/> <import plugin=" Org.eclipse.team.core "/> <import plugin=" Org.eclipse.ui "/> <impor T plugin= "Org.eclipse.update.core"/> <import plugin= "org.eclipse.ui.forms"/> <import plugin= "ORG.E" Clipse.ant.ui "/> <import plugin= org.eclipse.jdt.junit"/> <import plugin= "Org.eclipse.ui.intro"/&G T <import plugin= "Org.eclipse.ui.cheatsheets"/> </requires> <!--Extension points--> <extensio N-point id= "plugincontent" name= "%expoint.plugincontent.name" schema= "schema/plugincontent.exsd"/> <exten Sion-point id= "Newextension "Name="%expoint.newextension.name "schema=" schema/newextension.exsd "/> <extension-point id=" tem Plates "Name="%expoint.templates.name "schema=" schema/templates.exsd "/> <extension-point id=" samples "name="% Expoint.samples.name "schema=" schema/samples.exsd "/> <!--Extensions--> <extension point=" org.e Clipse.ui.perspectives "> <perspective name="%perspective.name "icon=" Icons/eview16/plu Gins.gif "class=" org.eclipse.pde.internal.ui.PDEPerspective "id=" org.eclipse.pde.ui.PDEPerspective "> </perspective> </extension>

The <export name= "*"/> declaration exposes all packages in the plug-in for use by other plug-ins. The Plug-in Dependencies Import section lists the necessary plug-ins required by the Org.eclipse.pde.ui plug-in.

The next two sections define the extension points that Org.eclipse.pde.ui can use for other plug-ins and its contribution to other plug-ins. In this example, you can see the definition of a custom Eclipse Plug-in Development Environment (PDE) view.

Here's 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= T.name "schema=" schema/plugincontent.exsd "/> <extension-point id=" newextension "Name="%expoint.newExtensi On.name "schema=" schema/newextension.exsd "/> <extension-point id=" Templates "name="%expoint.templates.nam E "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" Org.eclipse.pde.internal.ui.PDEPerspective "id=" org.eclipse.pde.ui.PDEPerspective "> </perspective& Gt

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.0 bundle-name:%name bundle-symbolicname:org.eclipse.pde.ui; Singleton:=true bundle-version:3.1.0 Bundle-classpath:org.eclipse.pde.ui_3.1.0.jar Bundle-Activator: Org.eclipse.pde.internal.ui.PDEPlugin Bundle-vendor:%provider-name bundle-localization:plugin require-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.base Bundle-manifestversion:2 Eclipse-autosTart:true Export-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-in imports are now specified as required bindings, * The package export has been replaced by an explicitly exported package list.

The plug-in-level dependency changes to a dependency that needs to be explicitly exported and imported, causing a lot of commotion when Eclipse announces the message. The main complaint is the lack of alternatives to the <export name= "*"/>, which already exists in earlier versions of Eclipse. However, there are many reasons for this omission. The most important reason is the speed gain from explicit import and export. Earlier versions of Eclipse must open and browse each plug-in jar file to determine which classes it contains. Excluding * Export also provides a primary protection to avoid exposing unnecessary classes to plug-ins. The plug-in developer must make a special selection to enable the functionality in the plug-in to be used externally. This restriction allows internal packages to remain internally.

OSGi Inventory Options

The OSGi R4 Framework Core Current draft specification is almost 300 pages in PDF format. Introducing each part of the specification is beyond the scope of this article, but I will discuss the OSGi MANIFEST.MF option that is of particular interest to the Eclipse plug-in developer: Bundle-activator This class is used to start and stop binding packages. In the example plug-in above, the Org.eclipse.pde.internal.ui.PDEPlugin class is specified. This class extends the Org.eclipse.core.runtime.Plugin and implements the Bundleactivator interface. Bundle-classpath This property specifies the ClassPath to use for the binding package. This property can contain a reference to a directory or jar file in a bundle jar file. You can use a period to indicate the root of a binding package. In the sample Eclipse PDE binding package, the Org.eclipse.pde.ui_3.1.0.jar in the bundle JAR file is specified. If the source version of the plug-in is imported into the workspace, the import process changes the bundle CLASSPATH to display as Bundle-classpath: This allows the development version of the plug-in to pick the compiled bundle class. Bundle-version This property specifies the version number of the binding package. Package import and the required bundle specification can include the bundle version number. Export-package This property specifies all packages that are publicly exposed to other plug-ins. Import-package This property specifies all packages to be explicitly imported from the required Plug-ins. By default, all packages must be resolved for the bundle to be started. Package imports can also be specified as optional to support a situation where the package does not exist. Explicitly imported classes are parsed before the packages in the Require-bundle plug-in. Require-bundle This property specifies the binding package to be imported for use in the given binding package and its exported packages. The specified binding package is parsed after an explicit package import.

Additional inventory options provided by Eclipse

Partner Class Loader options First create plug-ins for Hibernate. You then create a plug-in that contains domain-specific classes that have dependencies with Hibernate. Add the following lines to the Hibernate plug-in list: eclipse-buddypolicy:registered. Add the following list attributes to the list of plug-ins that contain domain-specific classes or resources: Eclipse-registerbuddy:hibernate. The line allows the plug-in to expose itself to the Hibernate plug-in by declaring that it is not aware of the plug-ins in advance. Now, the Hibernate plug-in can see the classes that are needed, although it does not specifically import them.

The OSGI specification includes MANIFEST.MF configuration options that do not provide all the functionality required by the Eclipse platform. As a result, the Eclipse creator added multiple extensions (and recommended that they be included in future versions of the OSGI specification):export-package Head ExtensionEclipse has two OSGi parser methods--default and strict that can be specified using the Osgi.resolver property. Eclipse also includes two extended--x-internal and x-friends for the Export-package property, which are enforced when Strict mode is enabled.x-internalThe default value for this property isfalse。 When you use this option to specify an internal package astrue, the Eclipse PDE prohibits its use.X-friendsThis option is similar to x-internal, but allows a specific binding package to use an exported package with that option. Other binding packages are prohibited. The x-internal option takes precedence over X-friends.Eclipse-autostartBy default, Eclipse loads the binding package as needed. Therefore, when the binding package for the first class that the binding package contains is required for this class, the bundle is loaded. Specify the value as??Causes Eclipse to load the bundle at startup. You can also specify the exceptions list, which are classes and resources that can be loaded without starting the binding package that contains them.Eclipse-platformfilterThis property allows the binding package to be started to be specified equal totrueThe conditions. The following information can be included in the specified expression: osgi.nl, which represents the language Osgi.os, represents the operating system Osgi.arch, represents the schema osgi.ws, and an example of how the window system shows how to use this property is when you start using SWT_AWT Bridge's plug-in before verifying that the operating system is MAC OS X. The MAC OS X implementation of Standard Widget Toolkit (SWT) does not currently support this feature. ）Eclipse-buddypolicyThis option specifies the class that loads the binding package policy. Typically, a bundle is visible only in its internal classes and in internal classes that are imported from a dependency bundle. The popular example used to explain partner class loading in Eclipse newsgroups is Hibernate. The Hibernate framework must look at the classes and resources created by the user rather than part of the Hibernate itself. One such scenario is when you use a project to dynamically populate a class from Hibernate query Language (HQL). By default, Hibernate will not be able to view classes that are outside the plug-in that contains the Hibernate jar file, and you need to modify the Hibernate plug-in to create each plug-in that contains classes that are not acceptable to the Hibernate map. Fortunately, the Partner Class loader option, which is described in the section on the Partner class loader options, solves this problem.

future trends for Eclipse and OSGi

Eclipse has benefited greatly from using OSGi, gaining a robust system for dynamically managing the lifecycle of components. New methods of use are being discovered every day, such as the server Layer feature servlet, JavaServer Pages, and other HTTP resources in the Eclipse style plug-in.

Eclipse Foundation has decided to play a key role in driving the OSGi specification forward, so that it can exploit osgi for itself and others. A number of additions to the OSGi specification were made during the transition from the dedicated Eclipse plug-in framework to OSGi, which was added as part of the OSGi R4 specification release. As a result, the Eclipse Equinox project has evolved into an evolving OSGi reference implementation. This implementation, together with the creation of Java specification Request (JSR) 291 for managing development OSGi, ensures that the ECLIPSE/OSGI partnership will continue to succeed in the years ahead.