url: /analysis/overview/
---
-<!-- sonarcloud -->
-## Prepare your organization
-
-A project must belong to an [organization](/organizations/overview/). You need to create one to analyze a project and collaborate with your team mates.
-
-[[info]]
-| ** Important note for private code:** Newly created organizations are under a free plan by default. This means projects analyzed on these organizations are public by default: the code will be browsable by anyone. If you want private projects, you should [upgrade your organization to a paid plan](/sonarcloud-pricing/).
-
-Find the key of your organization, you will need it at later stages. It can be found on the top right corner of your organization's header.
-
-## Run analysis
-
-SonarCloud currently does not trigger analyses automatically - this feature will come in a near future. Currently, it's up to you to launch them inside your existing CI scripts using the available scanners:
-* Gradle - [SonarScanner for Gradle](/analysis/scan/sonarscanner-for-gradle/)
-* MSBuild - [SonarScanner for MSBuild](/analysis/scan/sonarscanner-for-msbuild/)
-* Maven - use the [SonarScanner for Maven](/analysis/scan/sonarscanner-for-maven/)
-* Ant - [SonarScanner for Ant](/analysis/scan/sonarscanner-for-ant/)
-* anything else (CLI) - [SonarScanner](/analysis/scan/sonarscanner/)
-
-After creating a project, the tutorial available on its homepage will guide you to find how to trigger an analysis.
-
-[[info]]
-| Remember that depending on which cloud solution you are using for your developments, you can rely on dedicated integrations to help you:
-
-* [GitHub](/integrations/github/)
-* [Bitbucket Cloud](/integrations/bitbucketcloud/)
-* [Azure DevOps (formerly VSTS)](/integrations/vsts/)
-
-<!-- /sonarcloud -->
-
-<!-- sonarqube -->
Once the SonarQube platform has been installed, you're ready to install a scanner and begin creating projects. To do that, you must install and configure the scanner that is most appropriate for your needs. Do you build with:
* Gradle - [SonarScanner for Gradle](/analysis/scan/sonarscanner-for-gradle/)
A project is created in SonarQube automatically on its first analysis. However, if you need to set some configuration on your project before its first analysis, you have the option of provisioning it via Administration options or the **+** menu item, which is visible to users with project creation rights.
-<!-- /sonarqube -->
+
## What does analysis produce?
-{instance} can perform analysis on 20+ different languages. The outcome of this analysis will be quality measures and issues (instances where coding rules were broken). However, what gets analyzed will vary depending on the language:
+{instance} can perform analysis on up to 27 different languages depending on your edition. The outcome of this analysis will be quality measures and issues (instances where coding rules were broken). However, what gets analyzed will vary depending on the language:
* On all languages, "blame" data will automatically be imported from supported SCM providers. [Git and SVN are supported automatically](/analysis/scm-integration/). Other providers require additional plugins.
* On all languages, a static analysis of source code is performed (Java files, COBOL programs, etc.)
## Will all files be analyzed?
By default, only files that are recognized by a language analyzer are loaded into the project during analysis.
-<!-- sonarqube -->
-For example if your SonarQube instance had only SonarJava SonarJS on board, all .java and .js files would be loaded, but .xml files would be ignored.
+For example if you're using SonarQube Community Edition, which includes analysis of Java and JavaScript, but not C++, all `.java` and `.js` files would be loaded, but `.cpp` files would be ignored.
## What about branches and pull requests?
_Developer Edition_ adds the ability to analyze your project's [branches](/branches/overview/) and [pull requests](/analysis/pull-request/) as well as the ability to automatically decorate pull requests in some ALM interfaces.
-<!-- /sonarqube -->
## What happens during analysis?
During analysis, data is requested from the server, the files provided to the analysis are analyzed, and the resulting data is sent back to the server at the end in the form of a report, which is then analyzed asynchronously server-side.
1. Your plugin does not compete with existing or soon-to-be-released SonarSource products (sorry, but we gotta pay the bills somehow).
1. It is analyzed on [SonarCloud](https://sonarcloud.io/) and the quality gate is green when doing a release.
1. It is compatible with the platform requirements (e.g. it runs on the minimum listed JRE).
-1. If your plugin adds analysis of a language which is not analyzed by any SonarSource analyzer you must provide the NCLOC and NCLOC_DATA [metrics](/user-guide/metric-definitions/), which are both required to make the user experience within SonarQube consistent. You can take a look at how those metrics are provided by SonarJava ([NCLOC](https://github.com/SonarSource/sonar-java/blob/4cb1065f405edccbb7d229633945b3c56aeab04c/java-frontend/src/main/java/org/sonar/java/Measurer.java#L109), [NCLOC_DATA](https://github.com/SonarSource/sonar-java/blob/4cb1065f405edccbb7d229633945b3c56aeab04c/java-frontend/src/main/java/org/sonar/java/ast/visitors/FileLinesVisitor.java#L101)).
+1. If your plugin adds analysis of a language which is not analyzed by any SonarSource analyzer you must provide the `NCLOC` and `NCLOC_DATA` [metrics](/user-guide/metric-definitions/), which are both required for a consistent user experience. You can take a look at how those metrics are provided for Java ([NCLOC](https://github.com/SonarSource/sonar-java/blob/4cb1065f405edccbb7d229633945b3c56aeab04c/java-frontend/src/main/java/org/sonar/java/Measurer.java#L109), [NCLOC_DATA](https://github.com/SonarSource/sonar-java/blob/4cb1065f405edccbb7d229633945b3c56aeab04c/java-frontend/src/main/java/org/sonar/java/ast/visitors/FileLinesVisitor.java#L101)).
1. Last but not least: your plugin must be aligned with the goal of the SonarQube platform: management of the technical debt and the quality of the code.
To be more precise: every feature of SonarQube is tied to the code, so if your plugin provides data that can't be attached to a source or a test file, then there are chances that your plugin won't be accepted in the Marketplace
`pluginSourcesUrl` | Plugin-SourcesUrl | URL of SCM repository for open-source plugins. Displayed in page "Marketplace". Default: `${project.scm.url}`
`pluginOrganizationName` | Plugin-Organization | Organization which develops the plugin, displayed in the page "Marketplace". Default: `${project.organization.name}`
`pluginOrganizationUrl` | Plugin-OrganizationUrl | URL of the organization, displayed in the page "Marketplace". Default: `${project.organization.url}`
-`sonarLintSupported` | SonarLint-Supported | Whether the (language) plugin supports SonarLint or not. Only SonarSource analyzers (SonarJava, SonarJS, ...) and custom rules plugins for SonarSource analyzers should set this to true.
+`sonarLintSupported` | SonarLint-Supported | Whether the language plugin supports SonarLint or not. Only SonarSource analyzers and custom rules plugins for SonarSource analyzers should set this to true.
`pluginDisplayVersion` | Plugin-Display-Version | The version as displayed in SonarQube administration console. By default it's the raw version, for example "1.2", but can be overridden to "1.2 (build 12345)" for instance. Supported in sonar-packaging-maven-plugin 1.18.0.372. Default: `${project.version}`
As an exception, plugins must not package logging libraries. Dependencies like SLF4J or log4j must be declared with scope "provided".
### Exposing APIs to Other Plugins
-The common use case is to write a language plugin that will allow some other plugins to contribute additional rules (see for example how it is done in SonarJava). The main plugin will expose some APIs that will be implemented/used by the "rule" plugins.
+The common use case is to write a language plugin that will allow some other plugins to contribute additional rules (see for example how it is done for [Java](https://github.com/SonarSource/sonar-java) analysis). The main plugin will expose some APIs that will be implemented/used by the "rule" plugins.
Plugins are loaded in isolated classloaders. It means a plugin can't access another plugin's classes. There is an exception for package names following pattern `org.sonar.plugins.<pluginKey>.api`. For example all classes in a plugin with the key myplugin that are located in `org.sonar.plugins.myplugin.api` are visible to other plugins.
projects / sonarqube.git / commitdiff