Deployment of plugins under development is a bit faster with the command
mvn package org.codehaus.sonar:sonar-dev-maven-plugin:1.8:upload -DsonarHome=/path/to/install. JAR file is deployed and server is quickly restarted. It requires the development mode to be enabled on server (add
sonar.dev=true in conf/sonar.properties)
org.sonar.api.server.rule.RulesDefinitionto declare rules. It includes metadata related to technical debt model. It replaces the deprecated
Version 4.2 introduces a major feature that required deep internal refactoring : 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 for example. By following these rules, a plugin should be compatible with SonarQube 3.7+ and should support multi-language feature. The only exception is for plugins working on Java files. For these plugins there is no way to support at the same time 4.2 and prior versions because JavaFile/JavaPackage are no more supported in 4.2:
|Implementations of |
FooLanguage -> FooSettings -> Settings
|Language implementations and their dependencies (FooLanguage and FooSettings in the example) must be flagged with |
|Check project language, for example:|
Check existence of source files of the given language, for example:
|Extend ||Use |
|Use source directories :||Replace with:|
|Use constructors of ||Use |
|Check language of Quality profile:||Search for the active rules that relate to your rule repository:|
No alternative before 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 lower||Upgrade to sonar-commons-rules 1.2 : provide basic implementations of |
|Use resource scopes PGU (Scopes.PROGRAM_UNIT) and BLU (Scopes.BLOCK_UNIT), associated to classes ||Do not register classes, methods, functions and paragraphs. Keep these concepts internal to your plugin.|
|Use ||Implement your own Cobertura report parser in order to control way to locate files.|
|Java only - Use classes ||Use classes |
org.sonar.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 the 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 example in Javadoc.