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

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 :

• http://maven.apache.org/guides/mini/guide-maven-classloading.html
• https://cwiki.apache.org/MAVEN/maven-3x-class-loading.html

Sonar class loader during Ant execution is an Ant class loader :

• http://api.dpml.net/ant/1.6.4/org/apache/tools/ant/AntClassLoader.html

Plugin 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:

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

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

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

How to share classes between plugins 

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.