Message-ID: <1512078897.127.1429959570398.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_126_1302354103.1429959570397" ------=_Part_126_1302354103.1429959570397 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Deployment of plugins under development is a bit faster with the command=
mvn package org.codehaus.sonar:sonar-dev-maven-plugin:1.8:upload -Ds=
onarHome=3D/path/to/install. JAR file is deployed and server is quic=
kly restarted. It requires the development mode to be enabled on server (ad=
sonar.dev=3Dtrue in conf/sonar.properties)
org.sonar.api.server.rule.RulesDefinitionto decla= re rules. It includes metadata related to technical debt model. It replaces= the deprecated
Version 4.2 introduces a major feature that required deep internal refac= toring : support of multiple languages in the same project or sub-project. = No new API was developed but it requires some changes on existing plugins. = Some usages of API must be replaced. It does not require to upgrade= the minimum required version of SonarQube. It can still be 3.7 fo= r example. By following these rules, a plugin should be compatible with Son= arQube 3.7+ and should support multi-language feature. The only exc= eption is for plugins working on Java files. For these plugins the= re is no way to support at the same time 4.2 and prior versions because Jav= aFile/JavaPackage are no more supported in 4.2:
FooLanguage -> FooSettings -> Settings=
|Language implementations and their=
dependencies (FooLanguage and FooSettings in the example) must be flagged =
|Check project language, for example:
Check existence of source files of the given =
language through injected
|Use source directories :
|Use constructors of
|Check language of Quality profile:=
||Search for the active rules that r=
elate to your rule repository:
No alternative befor=
e 4.2. Use
Consequence : it's not possible to directly store measures = or issues on a directory before 4.2.
|Use sonar-commons-rules 1.1 or low= er||Upgrade to sonar-commons-rules 1.2=
: provide basic implementations of
|Use resource scopes PGU (Scopes.PR=
OGRAM_UNIT) and BLU (Scopes.BLOCK_UNIT), associated to classes
||Do not register classes, methods, = functions and paragraphs. Keep these concepts internal to your plugin.|
||Implement your own Cobertura repor= t parser in order to control way to locate files.|
|Java only - Use c=
org.son= ar.api.profiles.RulesProfilein batch extensions does not make sense= anymore. The list of active rules is available through the new class =
org.sonar.api.= batch.rule.internal.ActiveRulesBuilderfor your unit tests.
org.sonar.api.utils.text.XmlWriterFor information th= e next step is to provide the related readers.
org.sonar.api.utils.System2. It aims to improve = testability of classes that interact with low-level system methods. See exa= mple in Javadoc.