Skip to end of metadata
Go to start of metadata

Release 4.2

Changed

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:

 

(error) Before
(tick) After
Implementations of org.sonar.api.resources.Language could depend on module components (Project, Settings, ...). Example :
FooLanguage -> FooSettings -> Settings
Language implementations and their dependencies (FooLanguage and FooSettings in the example) must be flagged with @InstantiationStrategy(InstantiationStrategy.PER_BATCH)
Check project language, for example:
"php".equals(project.getLanguageKey())
Php.INSTANCE.equals(project.getLanguage())

Check existence of source files of the given language, for example:


// 3.7 or greater
"php".equals(project.getLanguageKey()) || (StringUtils.isBlank(project.getLanguageKey()) && !fileSystem.files(FileQuery.onSource().onLanguage("php")).isEmpty())

// 4.0 or greater
!fileSystem.files(FileQuery.onSource().onLanguage("php")).isEmpty()

Extend org.sonar.api.resources.File to handle its own tree of resources (for example ex-FlexFile)Use org.sonar.api.resources.File but never extend it
Use source directories :
File.fromIOFile(java.io.File file, List<java.io.File> sourceDirs)
ProjectFileSystem#getSourceDirs()
ProjectFileSystem#getTestDirs()
ModuleFileSystem#sourceDirs()
ModuleFileSystem#testDirs()
Replace with:
File.fromIOFile(java.io.File file, Project module)
ModuleFileSystem#files(query)

Notes :
  • ProjectFileSystem#getSourceFiles(Language...) and getTestFiles(Language...) can also be used, but it's recommend to replace by ModuleFileSystem.
  • (warning) File.fromIOFile(java.io.File file, Project module) has different behaviors in 4.2 and lower versions. It returns null on test files in SQ < 4.2. In order to be compatible with SQ 3.7 or greater, then the exact code should be :

    org.sonar.api.resources.File sonarFile = org.sonar.api.resources.File.fromIOFile(file, module);
    if (sonarFile == null) {
            // support SQ<4.2
            sonarFile = org.sonar.api.resources.File.fromIOFile(file, module.getFileSystem().getTestDirs());
    }

Use constructors of org.sonar.api.resources.FileUse File.fromIOFile(java.io.File file, Project module)
Check language of Quality profile:
RulesProfile#getLanguage()
Search for the active rules that relate to your rule repository:
RulesProfile#getActiveRulesByRepository(String)
Use org.sonar.api.resources.Directory

(warning) No alternative before 4.2. Use org.sonar.api.resources.Directory#fromIOFile(file, Project).

Consequence : it's not possible to directly store measures or issues on a directory before 4.2.

Use sonar-commons-rules 1.1 or lowerUpgrade to sonar-commons-rules 1.2 : provide basic implementations of org.sonar.commonrules.api.CommonRulesEngine and CommonRulesDecorator.
See sources of Flex plugin.
Use resource scopes PGU (Scopes.PROGRAM_UNIT) and BLU (Scopes.BLOCK_UNIT), associated to classes org.sonar.api.resources.Method and JavaMethodDo not register classes, methods, functions and paragraphs. Keep these concepts internal to your plugin.
Use org.sonar.api.utils.CoberturaReportParserUtilsImplement your own Cobertura report parser in order to control way to locate files.
Java only - Use classes org.sonar.api.resources.JavaFile and JavaPackageUse classes org.sonar.api.resources.File and org.sonar.api.resources.Directory

Added

  • Thanks to multi-language support, several Quality profiles can be enabled for the same project at the same time. Injecting the class org.sonar.api.profiles.RulesProfile in batch extensions does not make sense anymore. The list of active rules is available through the new class org.sonar.api.batch.rule.ActiveRules. See org.sonar.api.batch.rule.internal.ActiveRulesBuilder for your unit tests.
  • Write CSV, JSON and XML documents without coupling on any third-party library and in a performant way (streaming) :
    • org.sonar.api.utils.text.CsvWriter
    • org.sonar.api.utils.text.JsonWriter
    • org.sonar.api.utils.text.XmlWriter
      For information the next step is to provide the related readers.
  • New class org.sonar.api.utils.System2. It aims to improve testability of classes that interact with low-level system methods. See example in Javadoc.

Deprecated

  • Prototype.js and Scriptaculous.js are deprecated and will be dropped in 4.3. Please replace usages with jQuery. To prevent conflicts, jQuery uses "$j" and Prototype.js uses "$".

Release 4.3 (under development)

Plugin Development

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)

Added

  • New API org.sonar.api.server.rule.RulesDefinition to declare rules. It includes metadata related to technical debt model. It replaces the deprecated org.sonar.api.rules.RuleRepository.

Deleted

  • Classes JavaClass and JavaPackage, deprecated in 4.2, throw exceptions when being used.

To be documented : param sonar.rails.dev

  • No labels