Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

A plugin is a set of extensions

A Sonar plugin is a set of POJOs (Java objects) which implement extension points. These extension points are interfaces or abstract classes which model an aspect of the system and define contracts of what needs to be implemented. They can be for example pages in the web application or sensors generating some data.

The extensions implemented in the plugin must be declared in a Java class extending org.sonar.api.Plugin. This class must then be declared in the pom with the property <pluginClass> of the plugin sonar-dev-mojo :

Extension points

Here is list of extension points available in the sonar plugin API. Please note that partial implementation of those extensions are available in the api as well. Check the Javadoc for more information.

Batch side

What

Since

Description

org.sonar.api.batch.CpdMapping

1.10

CPD definition to detect duplicated lines on a new language

org.sonar.api.batch.Decorator

1.10

Used to decorate resources, i.e. calculate measures from other measures. Example : the number of lines of code of a package is the sum of the lines of its classes.

org.sonar.api.resources.Language

1.10

Define a new language.

org.sonar.api.batch.maven.MavenPluginHandler

1.10

Define a Maven2 plugin to execute before analyzing the project.

org.sonar.api.measures.Metrics

1.10

List new Metrics. A metric is an instance of org.sonar.api.measure.Metric. It can be quantitative (lines of code, number of rule violations) or qualitative (code coverage, complexity by class, rules compliance). As a rule, a metric is used to store a number but it can also be used to store a text field with list of key/value pairs, an XML or even binary data.

org.sonar.api.batch.PostJob

1.10

Post-jobs are tasks executed at the end of project analysis. Examples : purge database, generate report, send emails, ...

org.sonar.api.batch.Purge

1.11

Job to delete data from database.

org.sonar.api.batch.ResourceFilter

1.12

enables to ignore certain resources. The only implementations is the exclusion pattern management. (ExcludedResourceFilter in the core plugin).

org.sonar.api.batch.Sensor

1.10

Analyze project. It creates resources (classes, packages, ...) and measures. It can make requests on other systems. See below.

org.sonar.api.rules.ViolationFilter

1.12

Enables to ignore violations. Has a very simple interface : public boolean isIgnored(Violation violation). A NoSonarFilter draft has been added to the Squid plugin.

Server side

What

Since

Description

org.sonar.api.charts.Chart

1.10

Image generated by JFreeChart.

org.sonar.api.web.CodeColorizerFormat

1.12

Extend the library sonar-colorizer to support new languages. By default only Java sources are colorized in Sonar.

org.sonar.api.web.Footer

1.10

Static HTML footer displayed in all pages.

org.sonar.api.resources.Language

1.10

Define a new language.

org.sonar.api.web.GwtPage

1.11

Add a page, linked from the left sidebar. The page is implemented as a GWT component. GWT RPC/servlets are not supported.

org.sonar.api.web.ResourceViewer

1.10

New view when displaying source code. It is used to add a new tab to the source viewer along with "Violations", "Sources", "Coverage", ... The new tab is implemented as a GWT component.

org.sonar.api.web.RubyRailsPage

1.11

Add a page, linked from the left sidebar. The page is implemented as a JRuby on Rails view. 

org.sonar.api.web.RubyRailsWebservice

1.11

Experimental. Used to define new web services, written in JRuby on Rails. 

org.sonar.api.web.RubyRailsWidget

1.11

New widget in project dashboards. It is implements as a JRuby on Rails template.

org.sonar.api.rules.RulesRepository

1.10

This extension is used to define a new repository of rules, i.e. a list of coding rules to publish into the global rules referential. 

Sensor or Decorator ?

There are two extensions that enables to save measures : Sensor and Decorator. A common problem when writing a plugin is to decide which one to use.

Sensor

A Sensor is invoked once during the analysis of a project. The sensor can invoke a maven plugin, parse a flat file, connect to a web server... For example the Cobertura Sensor invokes the Codehaus Cobertura MOJO. Then the generated XML file is parsed and used to save the first-level of measures on resources (project, package or class).
A sensor has can access and save measures on the whole tree of resources. Sensor are generally used to add measure at the lowest level of the resource tree.

Decorator

Decorators are triggered once all sensors have completed. Their decorate method is called on every resource of a certain level bottom up. Decorators can load (SELECT) and save (INSERT) measures. The call is contextual, i.e it is only possible to access the resource and its children.
Decorators are generally used either to consolidate at higher levels measures that have been added by Sensors at the lowest level.

How to reuse existing components ?

Extensions are registered in an IoC container, with constructor injection.To communicate with other extensions or with existing components provided by the API, just declare them in the constructor of your extension. For example to get references on DatabaseSession or RulesProfile :

References will be automatically set at runtime.

Browse the javadoc and search for the the classes implementing org.sonar.api.BatchComponent and org.sonar.api.ServerComponent to get the list of all available components.

How to quickly start the plugin ?

As described in the Getting Started page, you can build sources, copy the JAR file to the directory extensions/plugins/ and restart the server. But this approach can quickly become tedious.

You can also execute the following Maven command without leaving your development environment :

The sonar-dev-mojo goal automatically starts a Sonar server which listens on the port 9000. The JAR file generated in the directory target/ of your project is automatically deployed.

Once the server is launched, hit the homepage (http://localhost:9000). By default, the in-process Derby database is used but you can specify to use a local MySQL instance with the property "-Ddatabase.profile=mysql". In that case, the sonar schema must exist in the MySQL DB along with the user sonar/sonar (login/password) who must have all rights on the sonar shema.

You can then feed the database by analyzing a project :

If you make changes on your plugin, those changes are not currently reloaded dynamically and you need to re-execute the sonar-dev-mojo plugin.

Note forMacOS

Icon

Add the property -Djava.io.tmpdir=/tmp to the mvn command.

How to use external libraries ?

to be defined

How to log ?

SLF4J is used as a simple facade of various logging frameworks (log4j, commons-log, logback, java.util.logging). It's simple to use :

Read the SLF4J manual for more details.

How to get the configuration ?

Configuration is loaded with the library Apache Commons Configuration. It includes properties from database, command-line parameters, system environment, maven (only for batch extensions) and conf/sonar.properties (only server extensions). To get a property value, add a dependency to org.apache.commons.configuration.Configuration in the constructor of your extension :

Some properties can be added to the plugins console (page Configuration -> Settings). Just annotate the Plugin class with :

Persistent properties are also accessible from the [Web Service|SONAR:Web
Service API] named 'properties'. To exclude some properties from anonymous requests, add the suffix ".secured" to the key ("my.property.key.secured"). It can be useful for example with license keys.

  • No labels