Preferences

Eclipse provides a preference dialogue which is subdivided in pages. Fortunately, it can be ex- tended and own preference pages can be added by extending theorg.eclipse.ui.preferencePages

extension point. Each page is defined by a name and a class extending the abstract class

FieldEditorPreferencePage, which provides useful methods to create GUI elements, as presented

by listing 7.1. The first parameter of the constructor of theBooleanFieldEditoris the preference

node identifier, the second parameter is the text displayed to the user with the ampersand indicating the next character to be the mnemonic character, and the last parameter is the parent SWT element.

Listing 7.1 Creating and adding a Boolean preference node.

addField(new BooleanFieldEditor("ID", "&Preference", getFieldEditorParent()));

Preferences are saved by a PreferenceStoreinternally. Each plug-in can specify an Activator

class, which is called as soon as the plug-in is loaded. The Activator class of each plug-in

inherits from AbstractUIPlugin. Each preference node needs a unique identifier. In order to

define the initial value of the preference nodes, a class extendingAbstractPreferenceInitializer

has to be added to the org.eclipse.core.runtime.preferences extension point. Its method initializeDefaultPreferences()is called whenever the preferences need to be initialized. More

information about Eclipse preference features is contained in [Dau08].

7.1.4 Scheduler and Event Analyzer Extension Points

New scheduler and event analyzer implementations should be added as separate plug-ins. To be informed about the existence of new plug-ins, the Eclipse extension point mechanism is used. The de.unistuttgart.iste.ps.savors.runtime plug-in defines two extension points in its

plugin.xml file as shown in listing 7.2.

Listing 7.2 Extension point definition for scheduler and event analyzer implementations.

<extension-point id="de.unistuttgart.iste.ps.savors.scheduler" name="Scheduler" schema=" schema/de.unistuttgart.iste.ps.savors.scheduler.exsd"/>

2 <extension-point id="de.unistuttgart.iste.ps.savors.eventAnalyzer" name="EventAnalyzer" schema="schema/de.unistuttgart.iste.ps.savors.eventAnalyzer.exsd"/>

The linked XSD documents were generated with the help of a user dialogue provided by the Eclipse Plug-in Development Environment (PDE). They define what information is required by the extension point. The scheduler extension point requires exactly one Java class implementing the ISchedulerinterface. The event analyzer extension point requires one Java class extending

theAbstractEventAnalyzerclass and two Boolean variables, specifying whether the event analyzer

should be selected initially and if it should notify the user in case of a detected event by default.

In theActivatorclass of the same plug-in defining the two extension points, the source code

of listing 7.3 will collect all elements of the scheduler extension point and add an instance of the specified class to the SchedulerManager. In the same way the elements of the event analyzer

extension point are loaded and added to theEventAnalyzerManager.

Listing 7.3 Loading elements of the scheduler extension point.

for (IConfigurationElement element : extensionRegistry.getConfigurationElementsFor(

SCHEDULER_EXTENSION_POINT_ID)) { 2 Object o = element.createExecutableExtension("class"); if (o instanceof IScheduler) { 4 SchedulerManager.addScheduler((IScheduler) o); } 6 } 7.1.5 Deployment

The set of plug-ins an Eclipse application consists of is defined in a product definition file. This file is an XML document which also allows to define the product’s branding details like

the launcher icon and the splash screen to be displayed while the application is started. It is contained in the plug-in de.unistuttgart.iste.ps.savors.

Adding every single plug-in to the product definition might become cumbersome, as all dependencies have to be taken care of. So-called feature definitions at an intermediate level between the product definition and the plug-ins provide relief. A feature is again defined by an XML document, specifying a set of plug-ins. In contrast to product definitions, it may also depend on other features. Therefore, instead of a long list of plug-ins, the product definition can also contain merely a few features. In order to use the Eclipse update mechanism Equinox Provisioning Platform (P2), a feature-based product definition is mandatory [Dau08].

With the help of the Product Configuration Editor, a special dialogue which is part of the PDE, the product definition file can easily be edited. This dialogue provides a reference to the

Eclipse Product Export Wizard, another dialogue helping to generate the application. If the

so-called delta-pack is installed within Eclipse, it is possible to export the product for various platforms, including Microsoft Windows, GNU Linux and Apple Mac OS X.

The building process internally relies on Apache Ant scripts. It is possible to create an own automated software building process with Apache Ant scripts by calling these internal scripts. An own building process can automatically create a JavaDoc documentation and invoke a coding style checking tool before building the software itself.

7.2 Visualization

The plug-in de.unistuttgart.iste.ps.savors.viewcontains all UI related classes like the handler

classes described in section 7.1.2, the edit parts introduced in section 6.4.1, and the views which are added to the main window of the Eclipse RCP application. The main view displays the simulation result synchronously to its generation. It is implemented in the class ScheduleView,

which extends the abstract classorg.eclipse.ui.part.ViewPart and is added to theorg.eclipse. ui.views extension point.