Message-ID: <1912066630.293.1430154760318.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_292_590681352.1430154760318" ------=_Part_292_590681352.1430154760318 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This article outlines the class loader hierarchy employed by Son= arQube and is intended to assist plugin authors in understanding what class= es/resources are accessible to their plugins at runtime.
The SonarQube classloader:
For each plugin, a classloader is created as a child of the SonarQube cl= assloader. 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 :
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 plug=
in explicitly exports a subset of classes. These classes must be defined in=
"org.sonar.plugins.<plugin key>.api" or any of its potential sub-packages. For this reason this feature is r=
eserved to the plugins hosted in the for=
ge of open-source plugins.
For example the DBCleaner plugin shares the class
s.dbcleaner.api.PeriodCleaner. Any plugin can use this class.