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.
The SonarQube 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:
A plugin can explicitly use the child-first model (see the property useChildFirstClassLoader). In this case, the search order is :
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.