This article outlines the class loader hierarchy employed by Sonar and is intended to assist plugin authors in understanding what classes/resources are accessible to their plugins at runtime.
Sonar class loader on server-side is a class loader provided by application server.
Sonar class loader during Maven execution is a Maven plugin class loader :
Sonar class loader during Ant execution is an Ant class loader :
For each plugin, a plugin class loader is created as a child of the Sonar class loader. By default plugin class loader 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 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 can not 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.