The home of Alitheia Core

The Alitheia core engine can be extended by plug-ins that calculate metrics. Metric plug-ins are OSGi services that implement a common interface and are discoverable using the plug-in administrator service. In practice, all metric plug-ins inherit from an abstract implementation of the plug-in interface and only have to provide implementations of 2 methods for each binding datatype (run() and getResult()) and the install() method to register the plug-in to the system.

Definitions

Below there is a list with definitions of common terms in the context of Alitheia Core:

Metric plug-in

An OSGi bundle that implements and exports the eu.sqooss.service.abstactmetric.AlitheiaPlugin interface

Asset

A collection of development data, such as a source code repository, a mailing list or a bug managemnet database

Project

A set of assets consisting of at least a Subversion repository and additionally a collection of mailing lists and a bug management system

Metric

An algorith that evaluates a property of a project asset or a change in a project asset and returns a result

Activation Types

Each metric plug-in is associated with a set of activation types. An activation type indicates that a plug-in must be activated in response to a change to the corresponding project asset; this is the name of the database entity that models the asset and therefore the metric is activated each time a new entry is added to the database table. Also, the plug-in can only return metric results for the supported activation types. An activation type is essentially the class type for the DAO that represents the asset type that the plug-in defined metrics can evaluate.

Currently, the supported activation types are the following:

• StoredProject Plug-ins implementing this activation type are triggered when a new project is added to the system. Metrics might can use this activation type to store project wide results
• ProjectVersion Metrics are activated when the a new project version is commited to the source code repository.
• ProjectFile Metrics are activated when a project file has been added, changed or removed from the source code repository.
• MailMessage Metrics are activated when a new mail message has arrived in a mailing list
• MailingListThread Metrics are activated when a miling list thread has been created or updated due to a new email that arrived to a mailing list.
• Bug Metrics are activated, when a bug has been created or its status has been updated.
• Developer Metrics are activated when entries about developers have changed (e.g. a new email alias was added)

Metrics

A metric plug-in can define several metrics, which are identified by a unique name (mnemonic). Each metric is associated with a scope that specifies the set of resources this metric is calculated against: for example files, namespaces, mailing lists or directories. Metrics can also declare dependencies on other metrics and the system will use this information to adjust the plug-in execution order accordingly through the metric activator service. The system administrator can also specify a set of policies regulating the recalculation frequency for each metric plug-in. Metric results are stored in the system database either in predefined tables or in plug-in specific tables. The retrieval of results is bound to the resource state the metric was calculated upon.

A few important things about metrics:

• Plugins define one or more metrics. A metric operates on a project asset and produces results (measurements).
• Metrics can produce an arbitrary set of results per evaluated project asset. Metric results can be of arbitrary data types.
• The result of a metric calculation is stored in the database. The Alitheia system provides a default storage facility for metrics for each one of the evaluated project assets. The default storage facility can only store a single value for each metric per evaluated resource type. However, plug-ins are free to implement custom DB tables for intermediate or final results, provided that the final results are associated with the project asset on which the metric operated.

Platform Services

A metric plug-in can use a wealth of services from the core to obtain project related data using simple method calls. For example, a metric plug-in can:

• request a checkout for a specific project revision or opt for a faster in-memory representation of the file tree and load the content of the required files on demand
• request a list of all threads a specific email has been sent to, and then navigate from the returned objects to the parent threads or to the mailing lists
• get all actions performed by a single developer across all project data sources, and
• request for a measurement calculated by another plugin. The system will automatically invoke the other plug-in if the requested measurement cannot be found in the database.