Skip to end of metadata
Go to start of metadata

This article outlines the class loader hierarchy employed by SonarQube and is intended to assist plugin authors in understanding what classes/resources are accessible to their plugins at runtime.

SonarQube Classloader

The SonarQube classloader:

Plugin Classloader

For each plugin, a classloader is created as a child of the SonarQube classloader. By default, the plugin classloader uses parent-first delegation model.

Search order for parent-first model:

  1. parent class loader
  2. classes exported from other plugins (see next section)
  3. classes in plugin

A plugin can explicitly use the child-first model (see the property useChildFirstClassLoader). In this case, the search order is :

  1. classes exported from other plugins (see next section)
  2. classes in plugin
  3. parent class loader

How to Share Classes Between Plugins 


This feature is implemented since version 2.4 for Maven 2 builds, and since version 2.5 for Maven 3 builds.

Each plugin has its own class loader, so by default a plugin cannot use a class defined in other plugins. This constraint can be bypassed if a plugin explicitly exports a subset of classes. These classes must be defined in the package "org.sonar.plugins.<plugin key>.api" or any of its potential sub-packages. For this reason this feature is reserved to the plugins hosted in the forge of open-source plugins.

For example the DBCleaner plugin shares the class org.sonar.plugins.dbcleaner.api.PeriodCleaner. Any plugin can use this class.

  • No labels