• Write the ids allways small - no camel case.
• Run Configuration is re-generated when the “Run As Eclipse Plugin” Link is clicked.
  
  This means that yout run-configuration are gone after clicking on that Link.

• Note that every Eclipse plug-in is essentially an OSGi bundle with some additional Eclipse-specific code.

Eclipse concepts

• Fragment projects - subprojects, which do work inside of a host project. Will be merged at runtime with it's parent project.
  Used for organizing unittests, because can access all resources, even those which are not a part of the external API.
  Used for organizing unittests localization files.
  <fc #FF0000>DON'T FORGET TO ADD THE NEW FRAGMENT PROJECT THE RUN CONFIGURATION</fc>

RCP concepts

• Eclipse Plugin - alias Component. alias Bundle in OSGi. In Eclipse everything is a plugin. The Plugin is the smallest logical unit. The Eclipse IDE allows the developer to extend the IDE functionality via plug-ins. Its a module, which implements some logic. It can be added or removed at runtime. Multiple plugin versions can be installed simularily. From the technical point of view a plugin is a set of files and a manifest.
• Dependencies - list of jar libs, which are required for this project
• Extenson points - Plugins define them. If a plugin defines an extension point - it allows other plugins to extend it's functionality by using the predefined contract. The contract is defined in form of an interface.
• Extensions - Plugins define them. To contribute functionality to another, extension-point defining host-plugin, the code is injected in form of an extension. Host-plugin knows, how to use the plugins' contributed functionality. Host-plugin talks to sub-plugins through an interface, defined by the host-plugn during the definition of the extension point.
• Feature - Contains a list of plugins and other features. Feature combines plugins and other features to a logical unit.
• Command - Command is a declarative (created in an xml, using a wizard) describtion of a component, which will be executed by this command. The implementation is inside the handler, independant from the component. Commands can be assigned to menus, toolbars, key bindings. Actions is the old pre-command concept, where the execution is not outsourced into a handler.

• RCP Application - A RCP Application is made of RCP plugins + the eclipse framework on which they run + custom plugins.
  • Applications are like the Java main() method. They are found and started by Equinox (OSGi implementation on Eclipse)
  • Applications seem to be like Activities in Android, because they implement a logically separated part of logic and work together in a branded product.
  • Applications are defined via the extension point org.eclipse.core.runtime.applications and must extend IApplication.
• Product - is one level above the applcation. A product has 1 to many applications, adds branding, icons, jar libraries to the product! A product allways points to an application, which will be started first, on product start. Since Eclipse RCP 4 a product is required to launch Appplications, before that a product was optional.

GUI

The details about what GUI part own what are listed here.
An Introduction into GUI extensions, which are listed below is found on eclipse's own page

• Views - GUI parts with a concrete functionality. (E.g. the view “Project Explorer” to display project's structure)
  • adding views as Standalone vs. non-Standalone - Views can become standalone, when they are added to the perspective. Views can be detached from the workbench and become an own window.
    (declaratively in a wizard or in code)
    
    The difference is:
    • the standalone views can't be put together, so that the View-Tabs are side by side.
    • the standalone views can hide own view-Toolbars by setting View's constructor parameter

      showTitle=false

• Editors - GUI parts for editing files of different types. (E.g. Text or HTML Editor). Contrary to the Views - Editors can't be detached from the Workbench.
• Perspective - defines the position, layout of views, editors needed for this perspective's purpose (E.g. Java-perspective). Perspectives are contained in workbenches.
  Think of perspectives as a set of layout hints for windows - they do not own the Views and Editor, just the layout Information. The WorkbenchWindow consults the perspective to do the initial layout.
• Workbench - the main Windows in Eclipse, which contains one or more persepectives. The Lifecycle and more info is found found here

   initialize - called first; before any windows; use to register things
  preStartup - called second; after initialize but before first window is opened; use to temporarily disable things during startup or restore
  postStartup - called third; after first window is opened; use to reenable things temporarily disabled in previous step
  postRestore - called after the workbench and its windows have been recreated from a previously saved state; use to adjust the restored workbench
  preWindowOpen - called as each window is being opened; use to configure aspects of the window other than action bars
  fillActionBars - called after preWindowOpen to configure a window's action bars
  postWindowRestore - called after a window has been recreated from a previously saved state; use to adjust the restored window
  postWindowCreate - called after a window has been created, either from an initial state or from a restored state; used to adjust the window
  openIntro - called immediately before a window is opened in order to create the introduction component, if any.
  postWindowOpen - called after a window has been opened; use to hook window listeners, etc.
  preWindowShellClose - called when a window's shell is closed by the user; use to pre-screen window closings
  eventLoopException - called to handle the case where the event loop has crashed; use to inform the user that things are not well
  eventLoopIdle - called when there are currently no more events to be processed; use to perform other work or to yield until new events enter the queue
  preShutdown - called just after event loop has terminated but before any windows have been closed; allows the application to veto the shutdown
  postShutdown - called last; after event loop has terminated and all windows have been closed; use to deregister things registered during initialize

• Coolbar alias Application Toolbar alias WorkbenchWindowToolbar - the main toolbar with command buttons at the top.
  
• View Toolbar - every View can have its own toolbar
  

SYSTEM

• WorkbenchAdvisor - is the invisible component, which controlls the apearance of the application
  (menus, toolbars, persepctives..)
  • initialize
  • preStartup
  • postStartup
  • postRestore
  • preWindowOpen
  • fillActionBars
  • postWindowRestore
  • postWindowCreate
  • postWindowOpen
  • preWindowShellClose
  • eventLoopException
  • eventLoopIdle
  • preShutdown
  • postShutdown
• WorkbenchWindowAdvisor - is the invisible component, which controlls the window. Every window has one.
  • preWindowOpen, which can set the window size, disable toolbars etc.
  • postWindowCreate, which has the knowledge about the existing window
  • postWindowOpen, which can add listeners to the existing window
  • preWindowShellClose, clean up
• ActionBarAdvisor - can add actions (commands) to any actionbar (menubar, toolbar etc.) inside the workbench
• BundleActivator Activator - Activator controls the plugin lifetime. This class gets events, when the plugin is loaded, installed, deleted etc.
• IApplication Application - classes, which implement this interface - represent a main entry point, means this class can be executed, if it was defined inside of the plugin.xml

When creating a new Eclipse RCP project, it is a good idea to do the following: Go to Eclipse Menu> Run> Run Configurations

What to do	Illustration
Let the Eclipse clear the workspace data on every launch, by setting the checkbox to clear on the “Main” Tab. Workspace data are everything, what is cached inside of the project. The cache is workspace dependant in Eclipse and is saved in .metadata folder.
Enable “all workspace and required plugins”
Let Eclipse clear the configuration area before launching. This is the location where Eclipse stores essential runtime metadata and cached data in general. Plug-ins may choose to store data here that should be available regardless the workspace in use (for instance, help index files). User settings shared across workspaces are also stored under this location.
Save the configuration as a persistent “shared file” in a separate Eclipse-Project (Common Tab)

• Extension Registry - Eclipse defines extension points (hooks) which Extensions use to hook in (contribute).
  The Information is added by using XML Manifests
  When the hook is activated - Equinox (OSGi) instantiates the class, which implements a predefined interface and calls run()

  // extension point is defined by Eclipse
  // org.eclipse.ui/plugin.xml
  <extension-point id="actionSets" name="Action Sets" />
  
  
  <?xml version="1.0" encoding="UTF-8"?>
  <?eclipse version="3.2"?>
  <plugin>
       <extension point ="org.eclipse.ui.actionSets" >">
         <actionSet id="org.eclipsercp.hperbola.debugActionSet" >
  	<action 
  		id="org.eclipsercp.hperbola.debug"
  		class="org.eclipsercp.hperbola.debugAction"
  		icon="icons/debug.gif"
  		label="Debug Chats" />
         </actionSet>
       </extension>
  </plugin>

During the compile time the compiler searches in this dependencies for the needed classes.

Run Configurations - are an Eclipse concept. Here the define Plugins, which your bundle depends on, <fc #FF0000>when run in IDE</fc>. Run Configurations are independant from what the dependencies, which are defined on OSGI level (in Plugins, Features, Products). The run configuration must contain the same dependencies as the dependencies on OSGI level.

The runtime configuration is an often seen error source.
For the new Project use the follwing run-configurations settings:
Go to Eclipse Menu > Run > Run Configurations > [your configuration]

• Set Eclipse to automatically validate the plugin dependencies on every run.
  Eclipse will see the missing plugins and warn you.
• Launch with “all workspace and enabled plug-ins”
  Eclipse will use all available plug-ins.

Alternatively you can choose needed plugins by doing “Add Required Plug-Ins”, instead of importing everything by choosing “all workspace and enabled plug-ins”.

In plugin.xml > Dependencies-Tab.

In plugin.xml > Dependencies-Tab.

Here the dependencies are entered on OSGI level. (as Bundles)
Here you can define dependiencies on bundles (plugins are bundles) by adding them to the Require-Bundle Point.

Require-Bundle: org.eclipse.ui,
 org.eclipse.core.runtime,
 de.ivu.fare.libs;bundle-version="0.0.0"

Maven maintains dependencies on its own. By using different extensions it can read dependencies from:

1. MANIFEST.MF
2. Eclipse RCP Plugins
3. Eclipse RCP Fragments
4. Eclipse RCP Features etc.

For the the right type should be defined inside of maven's onfig file “pom.xml”. Here is the full list of plugin types.

<fc #FF0000>VERY IMPORTANT</fc>

1. During the development the plugins are managed inside of the Eclipse IDE. When executed - the plugins are imported from the launch configuration. [Eclipse > Run > Run Configurations] There the plugins can be imported automagically by pushing [Plugin-Ins Tab > Add required Plugins]

2. Then, to be able to export the Eclipse application as standalone you have to add all dependant plugins to your applicaiton, without a Launch Configuration. For that export the plguin dependencies from the Runtime-Configurations to a feature and ad the feature to application dependencies.

   • go to [Eclipse > Run > Run Configurations > Common Tab]
   • share the run configuration by specifying a directory (it gives it a name automatically), apply and close the dialog.
   • Create a new Feature Project, call it something like 'org.com.product.dependencies'
   • Select Initialise from Launch Configuration and choose the one you just shared. Then include this feature in your Product Configuration. Voila!

a collection of Eclipse plugins, required for the own plugins. See this as a storage, with all libraries needed for your project.
A new Target is created as following:

1. Create a new project, to store the target
2. Create minimum two folders in the project: for the delta-pack and the rcp-sdk and maybe further folders for further plugins.
3. Delta-pack is needed needed to make the new plugin cross platform executable. Available under delta-pack zip.
4. Eclipse RCP-SDK, needed to use the rcp api. Available under RCP-SDK.
5. ATTENTION: the delta-pack and the sdk must have the same version!

1. Create a new Target Definition: New > Plug-In Development > Target Definition
2. Add the delta-pack and the rcp-sdk Directories to the locations, by using double-clicking on the new Target Definition.

The Target Platform is normally stored in a separate Eclipse project, to see the libaries in Eclipse's GUI.

The Target Platform can be switched for the whole IDE only:

The Views can be added in a special wizard or programmatically. Two steps are needed to create a new View:

1. Definition (definition in the wizard, backing by a View class)
2. Appending to a perspective, since perspectives do layout views

Editors are layed out automatically, by the workbench. For that reason they are not appended to the perspective. The initial, main perspective can only set Editors as visible or invisible.

Views are defined declarative, in the plugin.xml, by using a wizard:
Go to plugin.xml in your Eclipse RCP Project,
Go to the “Extensions Tab”
Use add to create a new “org.eclipse.ui.views” Extension , if there is none

Use Richtclick on “org.eclipse.ui.views” > New to create a new View.

Fill in the id an name and click on the “class” Link, to create a new Class. It is a good Idea to add a Static String “ID” to the new Class, with the dublicated id, which you have chosen in this step.

Views are added inside of the Perspective, altrough the Workbenchpage is the GUI part, which owns Views. The Perspective is responsible for views layout, so Views are added inside of the perspective.

Appending a View programmatically to the perspective:

package de.vogella.rcp.intro.view;

import org.eclipse.ui.IPageLayout;
import org.eclipse.ui.IPerspectiveFactory;

public class Perspective implements IPerspectiveFactory {

	public void createInitialLayout(IPageLayout layout) {
		layout.addView("de.vogella.rcp.intro.first.MyView", IPageLayout.TOP,
				IPageLayout.RATIO_MAX, IPageLayout.ID_EDITOR_AREA);

		//multiple instances of a view can be added to one Workbench, if allowMultiple="true" is set in plugin.xml
		layout.addView(View.ID+":1", IPageLayout.LEFT, 0.5f, IPageLayout.ID_EDITOR_AREA);
		layout.addView(View.ID+":2", IPageLayout.RIGHT, 0.5f, IPageLayout.ID_EDITOR_AREA);
	}
}

Appending a View declaratively, inside of the wizard:

Inside of plugin.xml, on “Extensions Tab” add a new “org.eclipse.ui.perspectiveExtensions” Extension
Append a new “perspectiveExtension” under the “perspectiveExtensions”
Append a new “view” with the previously defined id under the “perspectiveExtension”

Product can be creates as a

1. feature based
2. plugin based

The products should be maintained in separated projects.
This are the necessary points for product creation:

• create a “Plugin Project” for Products

• create a new “Product Configuration” inside the new project
• Product Configuration - contains product definitions inside of: plugin.xml > org.eclipse.core.runtime.products Extension
• Product Definitions in Product Configuration:
  • do know about the application, which will be executed on Product start / know
  • do know about the plugin, which is used to brand the product

• Choose wether your plugin is Feature or plugin based. <fc #C0C0C0>Dependencies are resolved differently.</fc>
  • feature based produkt <fc #C0C0C0>(Dependencies are managed by features)</fc>

<fc #FF0000> Feature based plugins need the org.eclipse.rcp in their Included-Features. Or there may be: </fc>

1. <fc #FF0000> plugin-validation problems (plugin dependency problems) </fc>
2. <fc #FF0000> java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter .. problems </fc>
   

• plugin based produkt <fc #C0C0C0>(Dependencies are managed by plugins, can be resolved automatically)</fc>
  • automatic dependencies resolution: product > Dependencies > “Add required Plugins” Button

The *.product is a come-together of many files, like ocnfig.ini, defining plugin and feature files. These files are not synchronized automatically with the plugin, which means that changing the product doesn't automatically change the files below.

<fc #FF0000>Explicite Synchronizing is required, which is done as following</fc>:

1. Push the “Synchronize” link inside of the product editor
   
2. Push one of the “Launch” Links inside of the product editor. The Plugin Development Environment will synchronize the product automatically.

before exporting add the required resources, since the eclipse adds automatically the java files only. To add the other resources, like images, css, icons, Application.e4xmi(in Eclipse RCP 4) set the hooks for required resources in the Build section of the build.properties

After that click “Eclipse Product export wizard” in the product Oberview-Tab.

Initial View can set Editors as

• visible or invisible,
• fixed or draggable
• or add the Views to the Editor? (why since, Views are not owned by Editors but by workbenchWindows?)

Example :

public class Perspective implements IPerspectiveFactory {
    public void createInitialLayout(IPageLayout layout) {
        String editorArea = layout.getEditorArea();
        layout.setEditorAreaVisible(true);
        layout.setFixed(true);
        layout.addStandaloneView(View.ID, false, IPageLayout.LEFT, 1.0f, editorArea);
    }
}

• The details about the command creation are listed here.
• The full list of Eclipse Command is listed here

Relevand Extension Points:

• org.eclipse.ui.command - define new commands here
• org.eclipse.ui.menu - define in which menues the command will be visible
  • the location is defined by the locationURI. LocationURIs are listed here
• org.eclipse.ui.handler - the Handler defines the behaviour of the command

The following steps are needed to define a new command:

• use an Extension Point org.eclipse.ui.commands
• add a new “Command”
• define a “defaultHandler” Class by clicking on the “defaultHandler”-Link. The Handler will implement the functionality of the command.
• override the command method isEnabled() to return true. Otherwise the command will be greyed out.
• override the command method isHandled() to return true. Otherwise the handler will not be called and an org.eclipse.core.commands.NotHandledException exception will be thrown

After that the command is defined, but will not appear anywhere yet. It should be explicitely added to the Toolbar or MenuBar.

The following steps are needed, to add command to a Menu on the MenuBar (the MenuBar on the Workbench-Window):

1. use an Extension Point org.eclipse.ui.menus
2. add a new “MenuControbution” with the following locationURI: menu:org.eclipse.ui.main.menu
3. add a new “Menu”
4. add a new “Command” to the menu. “New command”, because the command is added by doing rightClick>new>command.
   The “command” entry itself is not really defined here. It is only a crossreference(by id) to the previously defined command.
   The comands can be predefined by Eclipse or it can be your own commands.

Important: The following is done, when the comand is added to the menu, not when the command is created:

1. Icon definition is done every time, when the command is added to the menu
2. “Command Name” is done every time, when the command is added to the menu

On the picture two commands are added to the menu:

• previously defined “Say Hello” command
• eclipse defined “Exit” command

The following steps are needed to add the command to the ToolBar:

1. first make the Toolbar with the coolbar (toolbar with command-buttons at the top) visible by doing the following inside of the WorkbenchAdvisor.preWindowOpen:

   public class ApplicationWorkbenchWindowAdvisor extends WorkbenchWindowAdvisor {
   	...
   	public void preWindowOpen() {
   		configurer.setShowCoolBar(true);
   		...
   	}
   }

2. use an Extension Point org.eclipse.ui.menus
3. add a new “MenuControbution” with the following locationURI: menu:org.eclipse.ui.main.menu
4. add a new “toolbar”
5. add a new “Command” to the toolbar as. just as it can be done to teh menu. “New command”, because the command is added by doing rightClick>new>command.
   The “command” entry itself is not really defined here. It is only a crossreference(by id) to the previously defined command.
   The comands can be predefined by Eclipse or it can be your own commands.

To add a command to an exisiting, visible view do the following:

1. use an Extension Point org.eclipse.ui.menus
2. add a new “MenuControbution” with the following locationURI: toolbar:<viewIDtoWhichWeDoAddTheCommand>
3. add a new “Toolbar”
4. add a new “Command” to the toolbar as. just as it can be done to teh menu. “New command”, because the command is added by doing rightClick>new>command.
   The “command” entry itself is not really defined here. It is only a crossreference(by id) to the previously defined command.
   The comands can be predefined by Eclipse or it can be your own commands.

The dropdowns are represented by a fake-command with an ID fake-commandID in the toolbar.
The container, which contains the real commands is a MenuContribution with the id

1. The new fake-command is added to the toolbar (WorkbenchWindow or View's own toolbar)
2. The container, which contains the dropdown commands themselfes - is a MenuContribution with the locationURI “menu:fake-commandID”.

So 3 things are necessary to create a dropdown:

1. use an Extension Point org.eclipse.ui.commands to create a new fake-command, which will represent the dropdown
2. add the fake-command to the toolbar in some menu
   1. create a new “menuContribution” with a locationURI toolbar:org.eclipse.ui.main.toolbar
   2. add a new “toolbar” to the defined “menuContribution”
   3. add the fake-command to the new toolbar
3. add a “menuContribution” to Menus with a locationURI menu:<fake-command-id>.
   Here the commands, which should appear in the dropdown are added.

Every View can hava a context-menu. The describtion about the context-menu creation is here.

The details about Extension Points definition are here

In short, to define an extension point do:

1. define the extension-point
   1. Add a new extenson-point inside of the plugin.xml wizard > inside of the “Extension Points” Tab.
   2. The Wizard will link an *.exsd file, where the requirenments for the Extensions are defined at least. (e.g Extension should contribute a class, which implements Interface X)
   3. If the users of this extension-point will contribute a classes you will have to define an Interface for those classes to fulfill.
   4. Don't forget to make the package with the new interface public, by exporting it.
      
2. Write code to load the contributed functionality, which will be injected through the new extension point
3. use the loaded functionality inside of the extension-point provider (load views, tables, classes - whatever you need from external components)
4. implement plugins, which will contribute functionality, though the new extension-point

1. Inside of the plugin.xml wizard > inside of the “Extension Points” Tab define a new Extension Point
   
2. Inside the Schema-exsd-file create a new element, which will contain some requirements(required attributes) for the contributors to fullfill.
   

Loading the plugins, which contribute functionality by using my extension point.

For example inside of the Activator.start() you can do:

public class Activator extends AbstractUIPlugin {
 ...
	public void start(BundleContext context) throws Exception {
		super.start(context);
		plugin = this;
		
		//Evaluation of the extensions	
			System.out.println("Evaluation of Extensions in "+this.getClass().getName());
			//getting the Registry with the contributing extensions all existing extensions for the defined extension-point-ID
			final IConfigurationElement[] config = RegistryFactory.getRegistry()
					.getConfigurationElementsFor(
							IGreeter.IDS.EXTENSION_POINT_ID);
			
                ...
	}
 ...
}

Evaluate the contributed information. Do something with the new functionality.

In the same class, where the loading was done do:

public class Activator extends AbstractUIPlugin {
 ...
	public void start(BundleContext context) throws Exception {
		super.start(context);
		plugin = this;
		
		//Evaluation of the extensions	
			System.out.println("Evaluation of Extensions in "+this.getClass().getName());
			//getting the Registry with the contributing extensions all existing extensions for the defined extension-point-ID
			final IConfigurationElement[] config = RegistryFactory.getRegistry()
					.getConfigurationElementsFor(
							IGreeter.IDS.EXTENSION_POINT_ID);
			
                try {
				for (IConfigurationElement e : config) {
					System.out.println("Evaluating extension");
					final Object o =
							e.createExecutableExtension("class");
					if (o instanceof IGreeter) {
						executeExtension(o);
					}
				}
			} catch (CoreException ex) {
				System.out.println(ex.getMessage());
			}
	}
 ...
}

Use the new extension-point as you used eclipse-own extension points.

ATTENTION:
When defining own contributors and trying to run the Extension-Point Plugin with a new contributor-Plugin:
include the new contributor-plugin into the run-configuration:

In detail preferences are explained at Vogella and in an Eclipse Article

• Preferences are key/value pairs
• Abstract preferences are organized into into nodes in Eclipse. The root node is followed by special nodes, which are called scopes
  • Nodes are accessed as following:

    Preferences preferences1 = Platform.getPreferencesService().getRootNode().node(ConfigurationScope.SCOPE).node("pluginid");
    Preferences preferences2 = new ConfigurationScope().getNode("pluginid"); //same node is accessed

• Scopes are special Nodes. There 3 kind of scopes.
  • INSTANCE scope - If the user runs the same program twice, the settings between the two programs may be different.
  • CONFIGURATION scope - If the user runs the same program twice then the settings between the two programs are the same.
  • DEFAULT scope - Default values which can not be changed. Supplied via configuration files in plugins and product definitions.

*

To add preferences to your extension per Extension-Points:

1. use the extenson-point org.eclipse.ui.preferencePages to add preferences to the plugin
2. use the extension-point org.eclipse.core.runtime.preferences to add default values to the preferences, by introducing an initializer class
3. add a new Dependency org.eclipse.equinox.security to add secure, encrypted preferences to the plugin
   1. own password provider can be registered by using the extension point org.eclipse.equinox.security.secureStorage
4. create a new menu-entry to make preferences accessable, the details are explained under Eclipse - Rich Client Platform (RCP)
   1. use Extension Point org.eclipse.ui.menus to contribute to hook in into menu definitions
   2. create a MenuContribution with a locationURI named menu:org.eclipse.ui.main.menu and add a new menu
   3. add a new command named org.eclipse.ui.window.preferences which will diplay the preferences
5. accessing the preferences from different plugins is done by Platform.getPreferencesService().getString(…
6. listening to changes in the preferences can be done by implementing a IPropertyChangeListener()

To add a set of preferences to your extension programmatically:

1. Create a new PreferencePage. PreferencePages are objects, which represent the visible preference pages. They are responsible for:
   1. layout of the single preference pages
   2. reaction to OK / Apply Button, by sending data to the responsible storage
   3. assigning Editors of different type to every preference from the set of preferences
2. Create a new PreferenceNode. PreferenceNode represents the PreferencePage in the navigation-Tree, which is used to switch between PreferencePages.
3. Create a new PreferenceDialog. A PreferenceDialog window contains a hierarchical presentation of preference pages. Each page is represented by a node in the tree shown on the left hand side of the dialog; when a node is selected, the corresponding page is shown on the right hand side.
4. Add the PreferenceNode to the Root-Node or to another PreferenceNode by using a PreferenceManager. PreferenceManager organizes the PreferenceDialog by managing the PreferenceNodes and the PreferencePages behind them.

The preference pages inside of the preferences menu can be added as following:

• use the extension-point org.eclipse.ui.preferencePages with a new page
  
• implement a new page class, by inheriting from FieldEditorPreferencePage and implementing IWorkbenchPreferencePage
  (! the wizard makes the page class inherit from PreferencePage)

  public class MyPreferencePage1 extends FieldEditorPreferencePage implements IWorkbenchPreferencePage {
  	public PreferencesPage() {
  	   super(GRID);
  	}
  }

• implement init(IWorkbench workbench) which should prepare the preference storage for writing:

  setPreferenceStore(Activator.getDefault().getPreferenceStore());
  

• implement createFieldEditors() which should should fill the preference storage with values and assign some predefined editors to them

  	//registers predefined editors to the values
  	public void createFieldEditors() {
  		addField(new DirectoryFieldEditor("PATH", "&Directory preference:",
  				getFieldEditorParent()));
  		addField(new BooleanFieldEditor("BOOLEAN_VALUE", "&An example of a boolean preference", getFieldEditorParent()));
  		
  		addField(new RadioGroupFieldEditor("CHOICE",
  				"An example of a multiple-choice preference", 1,
  				new String[][] { { "&Choice 1", "choice1" },
  						{ "C&hoice 2", "choice2" } }, getFieldEditorParent()));
  		addField(new StringFieldEditor("MySTRING1", "A &text preference:",
  				getFieldEditorParent()));
  		addField(new StringFieldEditor("MySTRING2", "A &text preference:",
  				getFieldEditorParent()));
  	}
  

• use the extension-point org.eclipse.core.runtime.preferences to add default values to the preferences, by introducing an initializer class
• fill the default values in code

  public class MyInitializer extends AbstractPreferenceInitializer {
  
  	public MyInitializer() {
  	}
  
  	@Override
  	public void initializeDefaultPreferences() {
  		IPreferenceStore store = Activator.getDefault().getPreferenceStore();
  		store.setDefault("MySTRING1", "http://www.vogella.com");
  	}
  
  }
  

• Use Extension Point org.eclipse.ui.menus to contribute to hook in into menu definitions.
• Create a MenuContribution with a locationURI named menu:org.eclipse.ui.main.menu and add a new menu.
• Add a new command named org.eclipse.ui.window.preferences which will diplay the preferences.

Details were explained before, in Eclipse - Rich Client Platform (RCP)

The preferences can be acessed as following.

To listen for preference changes - register a new listener by the default Activator.

Important: Notice, that the method “Activator.getDefault()” only exists in RCP-Plug-Inprojects,
when they where created with the hook set by the setting “This plug-in will make contribution to the UI”.

If this hook was set the generated Activator will extend org.eclipse.ui.plugin.AbstractUIPlugin,
otherwise it will extend org.osgi.framework.BundleActivator

Activator.getDefault() retrieves a class, which controls the plugin life-cycle.

Activator.getDefault().getPreferenceStore()
	.addPropertyChangeListener(new IPropertyChangeListener() {
		@Override
		public void propertyChange(PropertyChangeEvent event) {
			if (event.getProperty() == "MySTRING1") {
				String value = event.getNewValue().toString()
				// do something with the new value
			}
		}
	});

The workbench toolbar can be filled with preferences programatically. This is done in the ActionBarAdvisor.

public class MainActionBarAdvisor extends ActionBarAdvisor {

    private IWorkbenchAction exitAction;
    private IWorkbenchAction aboutAction;
    private IWorkbenchAction preferenceAction;

    /**
     * {@inheritDoc}
     * 
     * @param configurer
     *            {@inheritDoc}
     */
    public MainActionBarAdvisor(final IActionBarConfigurer configurer) {
        super(configurer);
    }

    @Override
    protected void makeActions(final IWorkbenchWindow window) {

        exitAction = ActionFactory.QUIT.create(window);
        register(exitAction);

        aboutAction = ActionFactory.ABOUT.create(window);
        register(aboutAction);

        preferenceAction = ActionFactory.PREFERENCES.create(window);
        register(preferenceAction);

    }

    @Override
    protected void fillMenuBar(final IMenuManager menuBar) {
        final LocaleService ls = ServiceFactory.getLocaleService();
        final MenuManager fileMenu = new MenuManager(ls.translate(Messages.Menu_File), IWorkbenchActionConstants.M_FILE);
        final MenuManager helpMenu = new MenuManager(ls.translate(Messages.Menu_Help), IWorkbenchActionConstants.M_HELP);
        final MenuManager windowMenu = new MenuManager(ls.translate(Messages.Menu_Window),
                IWorkbenchActionConstants.M_WINDOW);

        menuBar.add(fileMenu);
        menuBar.add(windowMenu);
        menuBar.add(helpMenu);

        fileMenu.add(exitAction);

        windowMenu.add(preferenceAction);

        helpMenu.add(new GroupMarker(IWorkbenchActionConstants.MB_ADDITIONS));
        helpMenu.add(aboutAction);

    }
}

The details to this Topics are explained here

To set the language different from the Platfrom#s native language use the command Parameter -nl

-os ${target.os} -ws ${target.ws} -arch ${target.arch} -consoleLog -nl en
-os ${target.os} -ws ${target.ws} -arch ${target.arch} -consoleLog -nl de
-os ${target.os} -ws ${target.ws} -arch ${target.arch} -consoleLog -nl ru
-os ${target.os} -ws ${target.ws} -arch ${target.arch} -consoleLog -nl fr

The translations are maintained in *.properties files (LATIN-1 encoded)

• messages.properties: default language file, if nothing else is available
• messages_de.properties: used for German
• message_en.properties: default for English
• message_en_US.properties: US English file
• message_en_UK.properties: British English file

The main plugin should have one main language. Additional languages should be separated from the main plugin as Fragments and imported, when needed.

Use the Notation %keyname to get the language sensitive value from the *.properties file

Use a Tool to extract all the Strings from a plugin by doing:

Rightclick onto plugin.xml > PDE Tools > Internationalize

There you can extenralize all the String in plugin.xml and MANIFEST.MF

And you can choose languages, for which fragments should be created.

<fc #FF0000>After the fragments are created DON'T FORGET TO :</fc>

1. ADD THE NEW FRAGMENT PROJECT TO THE RUN CONFIGURATION
   
2. ADD THE “nl” FOLDER TO THE build.properties
   

To Test the new internationalization language add the “-nl <language>” argument to the run configuration:

-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl en
-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl de
-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl fr
...

In Elcipse the langauge switching may be done via Arguments. Either Java VM Arguments or Eclipse Arguments.

-nl iw

-Duser.language=iw -Duser.country=IL

When switching t oarabic or hebrew the UI may be switched to RTL View via the Eclipse Parameter

-dir rtl 

To move the *.properties to a package

1. move the *.properties into a package inside of the main plugin (e.g. package com.example.bang)
2. create a package with the same name in the Fragment. Don't bother if your main plugin has sources in another folder structre, like /src/main/java. Put the new package into /src , from there it will be merged with the /src/main/java in the main plugin at runtime.

\\main Plugin
src
 |_main
    |_java
      |_com.example.package
        |_ localization.properties
        
\\Fragment
src
  |_com.example.package
        |_ localization_en.properties

Choose the file you want to translate and do:

Menu > Source > Externalize Strings

This will generate a messages.property File and a Messages.class. The Messages.class will contains all the Strings you exported, which will be loaded at runtime.

To add an English translation of the exported Strings just add messages_en.property to the Project.
Or if you want to copy the messages_en.property to a separate Fragment - don't forget to copy put the messages_en.property into the same folder structure like the messages.property, so that it is merged to the right folder at runtime.

Use the Tool http://marketplace.eclipse.org/content/eclipse-resourcebundle-editor to compare translated Strings, to see incomplete translations only!

To set the language manually edit the config.ini file.

Prepend the following to the file /configurations/config.ini:

osgi.nl=es

A Product is required for Branding an Application. Following things can be customized:

• SplashScreen
• Icons (for the exe after the export)
• about dialog

The .exe Icons for each platform are set inside of the *.product file, on the Launchng-Tab.

The window icons are set inside of the Branding-Tab.

To set a custom Splash Screen - use the Splash-Tab, to choose the plugin, which will provide the SplashScreen.
The Splashscreen is provided as a splash.bmp file, in the root directory of the plugin.

Optionaly there can be a custom SplashScreen for every provided language. For that put the splash.bmp into a Fragment-Project, which will represent the Internationalization. Read more about Fragments for Internationalization above.
The right SplashScreen will be chose, depending on the -nl Run parameter: -nl fr_FR or -nl en Here are some examples:

org.eclipse.ui.examples.rcp.browser/
  nl/
    fr/
      FR/
        splash.bmp
        
org.eclipse.ui.examples.rcp.browser/
  nl/
    en/
      splash.bmp     

<fc #FF0000>IMPORTANT:</fc>
To define multiple, language specific SplashScreens they have to be added to the config.ini. (comma separated, with the slashes escaped)

osgi.splashPath=platform\:/base/plugins/de.ivu.fare.rcp.plugin,platform\:/base/plugins/de.ivu.fare.rcp.plugin.en

Since the config.ini is generated during the export - this parameter can to be set after each export, or defined once in the configuration-Tab. (comma separated, DO NOT ESCAPE SLASHES HERE)

About Product

• To add details-Information on the first level of the about dialog use the product-editor and don't forget to synchronize the product with it's plugin, after you change the text.
• This information can be localized by using an %aboutText variable and defining this variable inside of the plugin.properties
  

   
  ## product's branding-plugins's plugin.xml
  <property
      name="aboutText"
      value="%aboutText">
  </property>
  
  ## matching plugin.properties
  aboutText=aboutText=\n\nIVU.fare\n\n\
  Ticketing Backoffice System\n\
  \n\
  http://www.ivu.de
  \n\
  \u00A9 2012 Copyright IVU Traffic Technologies AG\
  \n

About Feature

• To add details-Information on the about_dialog>feature_dialog level add an about.ini to the project, where the property aboutText should be defined

  aboutText=%featureAboutText

• This information can be localized by using a %featureAboutText variable and defining this variable inside of the about.properties
  

   
  ## feature's branding-plugins's about.ini
  aboutText=%featureAboutText
  
  ## matching about.properties
  featureAboutText=aboutText=\n\nIVU.fare\n\n\
  Ticketing Backoffice System\n\
  \n\
  http://www.ivu.de
  \n\
  \u00A9 2012 Copyright IVU Traffic Technologies AG\
  \n

The help is normally outsourcesd into an own plugin. There are two types of help:

1. usual, big help dialog
   
2. context help, which is activated, when the focus is on a GUI part, for that the cotext help was defined.
   

To define a help dialog:

1. Create a plugin-project which will manage the help, by using the “Plug-in with sample help content” template:
   
2. For plugin-driven product add the folliwng plugin-dependencies:

    
   org.eclipse.help.ui
   org.eclipse.help.webapp
   org.eclipse.equinox.http.jetty

   or for feature-driven product add the following feature-dependencies:

   org.eclipse.help
   org.eclipse.ui.forms

3. make your product dependant on the help-providing plugin
4. embed following commands to open the help:

   org.eclipse.ui.help.displayHelp - Opens the help
   org.eclipse.ui.help.helpSearch - Open the Search

The context-sensitive help should be contributed by the help providing plugin. For add teh following to the plugin, which contributes the help:

1. create a new context.xml by doing new → Context Help
   
2. use the Extension-Point org.eclipse.help.contexts
   1. to point to the context.xml with the context help
   2. to point to the plugin, where the help will be activated (not to the plugin, which contains the help)
      

Inside the product project (not the help contributing plugin) use the code to add context sensitive help:

public class MyView extends ViewPart {
	
	public final static String ID = "de.vogella.rcp.intro.help.MyView" ;

	@Override
	public void createPartControl(Composite parent) {
		Text text = new Text(parent, SWT.BORDER);
		text.setText("Imagine a fantastic user interface with help here");

		
		//ADD CONTEXT-HELP TO THE PARENT. THE CONTEXT_HELP IS CONTRIBUTED BY ANOTHER PLUGIN
		PlatformUI.getWorkbench().getHelpSystem().setHelp(text, "de.vogella.rcp.intro.help.message");
...

Select the GUI Part, which you added teh help to and push F1 to open the context sensitive help.

Plugins are OSGI Bundles.
OSGI Bundles can only depend on OSGI bundles.
JARs have to be wrapped as OSGI Bundles to be used inside Plugins.

There is a Wizard, which allows to define a new Plugin, based on JAR libraries:

New> Other> Plug-in Development > Plug-In from Existin JAR Archivces