SOFA 2.0 Editor - GUI Repository Designer for Eclipse



SOFA 2.0 repository editor v. 1.3.0 released. Changes »


SOFA 2.0 repository editor v. 1.0.149 released.


Work on the plug-in is started. History »


Compiling and installation

User's manual

Usage scenarios

Developer's manual

UML diagrams

Java docs

Author MaViNes (c)


OSGI Framework

Eclipse plugin basics

RCP basics

SWT draw basics

jFace tips

SWT Linux/Windows differences

Author MaViNes (c)

<< Previous | Table of contents | Next >>

Chapter 2 Plug-in configuration

Bundle configuration

The plug-in main configuration is described in the META-INF/ file. This wile is required in order to compile valid working plug-in bundle. The manifest file contains following fields:
Manifest-Version - the version of the manifest file syntax. Usually it is 1.0
Bundle-ManifestVersion - the version of the manifest bundle.
Bundle-Name - the name of the bundle, which will be shown in the configuration manager. It will be also used in the bundle description, osgi debugging console and other technical and debugging parts of the Eclipse IDE. In our case the bundle is called SOFA 2.0 Repository Editor.
Bundle-SymbolicName - this is in fact the path to the root package of the plug-in. Also it indicates if the plug-in is singleton or not. If plug-in is defined as a singleton, then it can be initialized only once in the workbench.
In our case the value is: org.objectweb.dsrg.sofa.repository.plugin;singleton:=true
Bundle-Version - the version of the bundle. It is changed each time the new version is released. Now we have version 1.3.0.
Bundle-Activator - the name of the plug-in's activator. In fact it can be any file within the bundled package. So we haveto specify explicitly, which file is a bundle activator.
In our case this is org.objectweb.dsrg.sofa.repository.plugin.Activator.
Bundle-Vendor - the vendor of the bundle. For us this is
Bundle-Localization - it indicates if plugin is developed as a plug-in for Eclipse IDE, or if it is RCP, or some other kinds of possible plug-ins. For this project the value is plugin.
Require-Bundle - list of required bundles. The developed plug-in requires only those bundles, which are originally supplied with Eclipse IDE. Nothing additional should be installed.
Eclipse-LazyStart - indicates, whether the plug-in should be activated only when it is needed, or just at once the Eclipse is initialized. It is recommended to allow lazy start to free system resources. We allow it. The value is set to true.
Eclipse-RegisterBuddy - the root package: org.objectweb.dsrg.sofa.repository.
Export-Package - list of packages which are exported along with given plug-in. This means all java packages which are included in the project's implementation. The list should start not from the root package, but from the . to allow class path reference.
Bundle-ClassPath - list of jar libraries which should be included in plug-in's class path. In our case this is the whole lib/ folder. But all jars should be written one by one here. No wildcards are allowed.

All those fields are generated when the plugin.xml file is edited via plugin.xml editor in the Eclipse IDE. But some times it is required to edit it manually when generation is out of synch with the actual file. For example, when big refactoring is done and many packages are moved, renamed, or deleted. Then can be not updated automatically by the refactoring manager.

Extension points

The other very important configuration file is the plugin.xml file, which contains references to all extension and contribution points which are used in the project. The plugin.xml file is located in the project's root. Eclipse provides very user friendly plugin.xml editor. It allows making changes in all fields of the plugin.xml and automatically generates build.xml file for ant build and generates the file.

plugin.xml editor
Figure 2: plugin.xml editor

The editor is divided into pages. Each page provides separate group of properties to edit. The first - overview tab - is for general properties, like name, version, provider, activator class etc. This data is mainly used to generate the manifest file. The Dependencies tab gives possibility to edit plug-in dependencies list - the list of plug-ins which must be loaded into workbench in order to support correct functioning of the current plug-in This tab is used to make changes to the manifest file. The Runtime tab gives possibility to edit list of packages which should be exported with the current plug-in and define jar libraries which should be loaded in order for the plug-in to work. The jar libraries are not plug-ins, just some 3d parties libraries. This tab is used in the manifest file. The Extension tab gives possibility to add/edit/remove extensions to the workbench. This tab is used in the plugin.xml file. Using this tab it is possible to declare contributions to almost any part of the plug-in. Eclipse allows contributions to any place of the workbench - editors, views, actions, context menus, pop-up menus, tool bars, main menu, properties list, and many others. The Build tab gives possibility to define which files and folders will be included in the source and binary builds. Source build (which is obvious) is intended to include the folder with source java files. And on the other hand the binary build does not include the source folder. This is the main difference. The and plugin.xml tabs provides possibility of the raw editing of appropriate files.

<< Previous | Table of contents | Next >>

Learn More