Developer Documentation for Tooling Kernel (org.fortiss.tooling.kernel)

Plugin description

This plugin provides the non-UI services of the tooling kernel.

Each service is identified by a service interface, which provides the public interface to the service (see org.fortiss.tooling.kernel.service package). Most of the services are related to an Eclipse extension point and allow the application (built on top of the kernel) to extend its functionality with specific implementations. For example, the kernel provides an interface to cope with different storage solutions, which itself uses to provide a file based storage solution based on the Eclipse workspace. The extension point schemas for the kernel extensions can found in the schema folder of the plugins.

The kernel provides the following services:

Extensions to the kernel services are realized by implementing a handler interface provided by the kernel (see org.fortiss.tooling.kernel.extension package). In the communication between the kernel and its extensions, additional data may be required (see org.fortiss.tooling.kernel.extension.data package) or exceptions may be raised (see org.fortiss.tooling.kernel.extension.exception package). The kernel also provides abstract base implementations for most of the handler interfaces, which are located in the org.fortiss.tooling.kernel.extension.base package.

Metamodel description

Tooling Kernel Metamodel Classes

UML diagram of Tooling Kernel

The root package of the tooling kernel metamodel consists of the following classes:

The constraints sub-packages contains the following meta-classes required for the IConstraintService-based constraint verification mechanism (see below):

Package Overview

In the following, we describe the top-level packages of the Tooling Kernel plugin.

constraint

Package providing several basic IConstraintChecker-based constraint checkers (supported by IConstraintCheckerService).

Note that the kernel also provides IConstraint-based constraints (supported by IConstraintService).

extension

Interface definitions for extension classes of kernel extension points.

Each interface corresponds to one extendable service from the kernel.service package and therefore to one extension point schema definition.

A plugable extension must implement the methods of the respective interface in order to work properly with the kernel implementation. These methods are called by the kernel at the appropriate time, e.g., a IPrototypeProvider is required to provide its prototype elements when the kernel calls the getPrototypes() method.

The communication between the kernel and extensions usually involves some kind of data (e.g. Prototype). These data-related classes and interfaces can be found in the kernel.extension.data package.

For some extensions the kernel provides abstract base implementations in the kernel.extension.base package.

extension.base

Base implementations for extension classes of kernel extension points.

extension.data

Interfaces and classes for data transfer between the kernel and extensions.

The classes and interfaces of this package appear as parameter and result types of the interfaces in the kernel.extension package. Parameter objects resemble additional context data provided to the extension, while result objects are required from the extension.

On the kernel level the context information is usually empty, i.e., the respective interface is only a marker interface. Higher layers of the tool architecture may extend these interfaces with additional pieces of information. Here, the kernel is only the mediator between plugable parts of the tool.

Some of the result objects provide additional methods, which are used by the kernel at a later time after requesting it from the extension (e.g. once the ITopLevelElement is known to the kernel, the runAsCommand method will be called whenever some change to the model must be applied).

extension.exception

Exception classes for failure reporting between the kernel and extensions.

internal

Implementations of the kernel services defined in the kernel.service package. Kernel services are only accessible through the singletons defined in the kernel.service package. The implementation in this package are not intended to be used directly. Therefore they are not exported in the plugin.xml.

internal.storage.eclipse

Implementation of the IStorageProvider interface using Eclipse file resources as storage mechanism for models.

This storage provider searches all projects in the Eclipse workspace for model files. Only files in the project's root folder are considered. For each such files the set of registered eclipseResourceStorageLocationProvider extensions is asked whether the respective file should be considered a model file. This extension mechanism is used to allow independent tools (running in the same Eclipse instance or two RCPs running independently) to use different file extensions for their models, e.g., tool A uses file pattern *.toolA, while tool B uses the file pattern *.toolB. The file extension is usually a hint on the meta-model class of the contained root model element.

introspection

Interface definitions of the kernel introspection system service (KISS).

Each kernel service should implement the IIntrospectiveKernelService interface to provide useful runtime information and a brief documentation its design and objectives.

KISS is intended to be used by the tool developers to ease the development of kernel based tools.

introspection.items

Item definitions for the kernel introspection system service (KISS).

Each kernel service may provide specific runtime information items, which are presented by some tool developer view or console.

Classes in this package are public, since they need to be shared by the user interface implementation.

service

Interface definitions of the kernel services. Each interface corresponds to a certain functionality of the kernel.

Some of the services provide extension points. Extension implementors should refer to the kernel.extension and kernel.extension.base packages. Kernel services are implemented by classes from the kernel.internal package.

service.base

Abstract base implementations for the kernel services. These classes my also be used for implementing plugability in higher layers of the tool architecture.

service.listener

Classes in this packages are listener interfaces for kernel services.

Sometimes higher layers of the tool architecture must be able to know what is happening in the kernel layer. Therefore, they can implement the respective listener interface and register themselves with the respective kernel service.

utils

Utility methods provided by the kernel.