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 (
getResult()) and the
install() method to register the plug-in to the system.
Below there is a list with definitions of common terms in the context of Alitheia Core:
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:
StoredProjectPlug-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
ProjectVersionMetrics are activated when the a new project version is commited to the source code repository.
ProjectFileMetrics are activated when a project file has been added, changed or removed from the source code repository.
MailMessageMetrics are activated when a new mail message has arrived in a mailing list
MailingListThreadMetrics are activated when a miling list thread has been created or updated due to a new email that arrived to a mailing list.
BugMetrics are activated, when a bug has been created or its status has been updated.
DeveloperMetrics are activated when entries about developers have changed (e.g. a new email alias was added)
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:
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: