side by side usage of C++ commercial and community plugin

[guwirth]

As an user I like to use the C++ commercial and community plugin in parallel on the same server.

• should be possible to install both plugins on the same server
• settings should not conflict in configuration file
• should be possible to mix sensors of both plugins

[guwirth]

Commercial plugin settings to keep in mind making the plugins working side-by-side.

C / C++

C file suffixes

Comma-separated list of suffixes of C files to analyze.
Key: sonar.c.file.suffixes

C++ file suffixes

Comma-separated list of suffixes of C++ files to analyze.
Key: sonar.cpp.file.suffixes

Objective-C file suffixes

Comma-separated list of suffixes of Objective-C files to analyze.
Key: sonar.objc.file.suffixes

Coverage

Bullseye XML report

Path to the Bullseye XML Coverage Report. The path may be either absolute or relative to the project base directory.
Key: sonar.cfamily.bullseye.reportPath

Gcov reports

Path to the directory containing the *.gcov Gcov report files. The path may be either absolute or relative to the project base directory.
Key: sonar.cfamily.gcov.reportsPath

llvm-cov report

Path to the Coverage Report generated by "llvm-cov show". The path may be either absolute or relative to the project base directory.
Key: sonar.cfamily.llvm-cov.reportPath

Visual Studio XML reports

Pattern for search for Visual Studio Coverage XML reports. The pattern may be either absolute or relative to the project base directory. For example: "**/.coveragexml" will find all ".coveragexml" files in all sub-directories of current project.
Key: sonar.cfamily.vscoveragexml.reportsPath

Tests

CppUnit reports

Path to the directory containing the *.xml CppUnit report files. The path may be either absolute or relative to the project base directory.
Key: sonar.cfamily.cppunit.reportsPath

Miscellaneous

Ignore header comments

If set to "true", the file headers (that are usually the same on each file: licensing information for example) are not considered as comments. Thus metrics such as "Comment lines" do not get incremented. If set to "false", those file headers are considered as comments and metrics such as "Comment lines" get incremented.
Key: sonar.cfamily.ignoreHeaderComments

Deprecated

C language standard

This property is deprecated, because the build-wrapper gathers this information automatically.
Key: sonar.c.std

C++ language standard

This property is deprecated, because the build-wrapper gathers this information automatically.
Key: sonar.cpp.std

Comma-separated list of lines that are passed into the preprocessor

This property is deprecated, because the build-wrapper gathers this information automatically.
Key: sonar.cfamily.predefinedMacros

[guwirth]

Quality profiles, today there is:

• C++
• c++

This is confusing maybe we should change it to C++ (Community) or also C++.

[guwirth]

Rules, today there is:

• Language
  • c++
  • C++

This is confusing maybe we should change it to C++ (Community) or also C++.

[guwirth]

C / C++ / Objective-C

• Language
  • C++
    • key: cpp:nnnnn (e.g. cpp:S3805)
  • C
    • key: c:nnnnn (e.g. c:S3805)
  • Objective-C
    • key: objc:nnnnn (e.g. objc:PPBadIncludeForm)

C++ (Community)

• Language
  • c++
    • key: cxx:nnnnn (e.g. cxx:UseCorrectInclude)

[guwirth]

For my understanding dependencies are like this:

• jar <=> plugin 1:1
  • plugin key must be unique
  • plugin <=> language 1:n
    • language: unique key, unique file extension
  • plugin <=> sensor 1:n
    • sensor: general, one or more languages
  • plugin <=> profile 1:n
    • profile <=> language 1:1
  • plugin <=> repository 1:n
    • repository <=> language 1:1

[andrewjlawrence]

Is there anymore work that needs doing for this issue?

[guwirth]

@andrewjlawrence for the cpp and cxx it should work. They have unique names now. Work means:

• installation of both plug-ins in parallel on on server
• use the one plugin for the C++ language or the other

To turn on/off a plug-in you have to set always one of the two suffixe settings to an invalid value, e.g. .xyz:

• sonar.cpp.file.suffixes
• sonar.cxx.suffixes.sources

This is a workaround - don't know how we solve this in future.

[amai2012]

Isn't this a duplicate to #1345?

[guwirth]

Isn't this a duplicate to #1345?

@amai2012 no, because there is a C and a C++ plugin. Both has own independent language keys.

[Kristouff]

We are also having this issue as we would like to mix sensors from both plugins. We contacted Sonar for this issue some time ago (mid 2016) and got this answer:

This is correct to say having the 2 plugins installed on the same SQ instance won't allow you to use both of the features at the same time on the same project.
This is mainly linked to the suffix configuration and also the fact the Cxx Sensors are expecting to work with files corresponding to the language "c++", while we are working with the language "C++" (note the case). If you disable the Cxx Sensors by changing the suffix configuration, none of the other PCLint, Valgrind, GCovR or GoogleTest Sensors will execute.
Some customers just interested by PCLint or Valgrind rules, wrote their own plugin based on the https://github.com/SonarSource/sonar-examples/tree/master/plugins/sonar-example-plugin we are providing to show how to load results produced by an external tool.
One other options could be to clone https://github.com/SonarOpenCommunity/sonar-cxx, remove all the code related to Static Code Analysis and other tools you don't care and change the Sensors so that they work with our language, C++, recompile and so build you own version of the Cxx Community plugin.
As an example for Valgrind (https://github.com/SonarOpenCommunity/sonar-cxx/blob/master/sonar-cxx-plugin/src/main/java/org/sonar/plugins/cxx/valgrind/CxxValgrindSensor.java), it will consists on changing just this line:
public void describe(SensorDescriptor descriptor) {
descriptor.onlyOnLanguage("C++").name("CxxValgrindSensor");
}

I don't know if this is of any help for you but this may be a track to follow.

[guwirth]

@Kristouff the use case cpp and cxx plugin installation on one server is supported. You can also use the one or the other plugin (it's an xor). Mixed mode (reading files with cpp plugin and using cxx sensors) is not supported yet. Also don't know if this is possible? Would mean some thing like register sensors for both language keys (cxx and cpp)?

[Kristouff]

The ideal solution would be to mix advantages of both cpp and cxx plugins by appending cxx sensors results to cpp plugin analysis.

In details, we are looking for implementation of the following analysis sequence :

• analyse with cpp plugin
• import gcc warnings with cxx compiler sensor
• import cppcheck static analysis results with cxx cppcheck sensor
• import unit test results in GoogleTest format with cxx xunit sensor
• import coverage results in cobertura format with cxx coverage sensor
• import valgrind memcheck dynamic analysis results with cxx valgrind sensor
  with all these results consolidated in a single SQ project for each analysis.

Maybe this is not possible, but it could also be interesting to have cxx plugin analysis results to extend cpp plugin ruleset.
I assume I am not the only one looking for this possibility as you already mentionned this solution in issue #1328.

[guwirth]

@Kristouff thanks for your feedback. Think there are several things to take into account. I'm also not sure if there is another sample where two plugins are supporting one language.

• First step is always reading and indexing the source files. It must be somehow ensured that only the cpp plugin is doing this. As a workaround this can be done by setting invalid file extensions to the cxx plugin.
• Second our plugin must support both "languages" with the language keys cpp and cxx. This would mean to register all sensors for both language keys. This should be possible. SonarSource C/C++ plugin is also only one plugin supporting two languages.
• Third problem: We need someone who is implementing this :-). Are you willing to contribute?

[Kristouff]

@guwirth It's been a long time since my last post but the need is still present.
I finally took some time to check for feasability and put my hands in the sources even if it has been a long time since I wrote some JAVA for the last time.
Anyway, I could succeed in extending CFamily (commercial) plugin with Sonar-Cxx sensors and rules. I proceeded as follows:
First I forked the latest version of the project to my repositories. (Maybe I should have created a pull request? I am not very familiar to GitHub habits...)
I added a standalone plugin sonar-cxx-cfamily
This plugin instantiates cppcheck, coverage and valgrind sensors applied to CFamily language (key=cpp) and adds the cppcheck and valgrind rules to the CFamily language in dedicated repositories. For now I limited to a small number of sensors to first check it is feasable (and also they are those we are using :) )
One thing to note is that no language is added by this plugin as it relies on the CFamily language which is already added by the CFamily plugin.
Deploying it without having the CFamily plugin does not fail but as the language will not exist, rules will not be associated to any language and it will not be usable anyway. So that is the advantage of having a dedicated plugin, you can decide not to deploy it with the sonar-cxx plugin.
I also tried to extend CFamily language with the SonarAnalyzer sensor but could not succeed as I got an exception at SQ startup which I could not solve : org.picocontainer.injectors.AbstractInjector$UnsatisfiableDependenciesException: org.sonar.plugins.cxx.cfamily.CxxCFamilyRuleRepository has unsatisfied dependency 'class org.sonar.cxx.CxxLanguage' for constructor 'public org.sonar.plugins.cxx.cfamily.CxxCFamilyRuleRepository(org.sonar.cxx.CxxLanguage)'

This work must be seen as a proof of concept, I think.
So for instance, I would like to let you look at it and let you make some feedback.

[guwirth]

@Kristouff your comment is older but some feedback to it. SonarQube is always working in two steps:

1. Reading the source code files (indexing). There must be one (and only one) plugin which is supporting files with an unique file extension. After the files are in the database:
2. Executing sensors assigning issues to the indexed files.

So instead of copying the code the easier way is to index the files with the commercial plugin (set there the file extensions) and disable it in the community plugin (set a dummy file extension, e.g. .dummy). Then you can use the other sensors of the community plugin to read reports.

[guwirth]

cxx plugin v2.0:

• cxx plugin is using 'cxx' language key now (before c++)
• there is no more C support (with c key). There was a conflict with SonarCFamily plugin.
• cxx sensors for external reports are supporting languages with keys: cxx, cpp and c
• For reading in (indexing) the files, you have to decide whether you want to use the cxx plugin or the SonarCFamily. With SonarQube, file types can only be uniquely assigned to one programming language via the file extension. Several plugins cannot define the same programming language (language key). Therefore the cxx plugin uses cxx as language key and SonarCFamily uses cpp for C++ and c for C. The file extension must be deactivated in the respective other plugin(s): Each file extension may be defined only once in the sonar.cxx.suffixes.sources, sonar.cpp.file.suffixes or sonar.c.file.suffixes settings.
• The rules are configured consistently in the Quality Profiles under CXX.
• see also SonarCFamily support #2018