Doxygen report file support

[tomikais]

Hello,

this is a suggestion for a new function (very low priority). It would be helpful to have the Doxygen warnings and issues in SonarQube.
This could be implemented similar to the Visual Studio log file parser.

Regards, Thomas

[JStb]

I have a an incomplete set of sonar.cxx.other.rules for doxygen logfiles plus a python converter from doxygen.log to a cxx-reports.xml file.
Unfortunately I was not able to find a complete set of warnings in the doxygen src.

[jmecosta]

@JStb you are more than welcome to add your definitions (even if incomplete) to https://github.com/SonarOpenCommunity/sonar-cxx/wiki/Extending-the-code-analysis#resources and make the convertes availalbe here: https://github.com/SonarOpenCommunity/sonar-cxx/tree/master/sonar-cxx-plugin/src/tools

the idea was that anyone can add more tools there

[guwirth]

@JStb agree with @jmecosta you are welcome to add your scripts.

On the long run it would be better to write an own sensor for this. Agree that it is more or less a copy of the compiler sensor (https://github.com/SonarOpenCommunity/sonar-cxx/tree/master/sonar-cxx-plugin/src/main/java/org/sonar/plugins/cxx/compiler)

sonar.cxx.doxygen.rules=...
sonar.cxx.doxygen.reportPath=...

[JStb]

I just got the go to contribute from my employer. I'll refactor the converters a bit and them put them online.

an own sensor would be nice, but as doxygen is not bound to any language... does it make sense to put it in sonar.cxx.doxygen?

[jmecosta]

@JStb what about creating the sensor in the doxygen plugin? https://github.com/SonarQubeCommunity/sonar-doxygen that way it will not bee bound too C++ only

[guwirth]

@JStb we have a lot of sensor in this plugin couls also be isolated in an extra plugin. Question is always how much effort it is to maintain an own plugin (and who is willing to do it). Adding it here is one XML file describing the rules and two small Java files.

[jmecosta]

@guwirth you are forgetting the support for troubles that might or not show up in future. Once this grows to have n+1 sensores becomes difficult to provide support.

Earlier with @wenns the decision in these cases was always to use the external sensor. That's the reason the cpplint sensor was imported as external sensor. Of course we can change this, and create the n+1 sensores, but I do agree with the support part of it might be a issue.

To me this would be a good addition to the doxygen, at least I would like to have it there. For 6.3 Sq, I will try to get the plugin to display the doc inside Sq. So both these would make the plugin very useful

[JStb]

I really love the XML support of the community cxx plugin. For me it's no big deal, to write the rules.xml file and create the results.xml files as well. I wish I had that for other languages I use!
I'm currently thinking of an extra plugin which is language independent and just provides the possibility to inject new rules and issues via XML (if only my java experience would be better and I had a bit more time)
I'm still on sonarqube server 5.1 because of an old ada plugin.

[jmecosta]

@JStb :) i thought about that earlier also. but usually almost all language plugins provide a way to extended with custom rules, those are sslr based rules or template rules of sort. so did not pursued that much. for my usage c++ and the external sensor is more than enough, we have cpplint, intel inspector and some custom in house tools uploaded with that. Perhaps is not a bad idea just to take the external sensor and call it external plugin that can be used for anything we would like :)

[JStb]

Just 9 months later...
we (ok, to be honest, my intern) are currently setting up a new plugin.
It will be language independent, very simple. Idea is to be able to create new languages, define metrics and rules and inject them with sonar-scanner via xml files.

[guwirth]

Could be on top of #1533

[guwirth]

Steps to do:

• Extract warnings/error messages from Doxygen to create rules. Rules are the precondition to create Quality Profiles.
• Write a parser to read Doxygen .LOG file and extract issues and assign it to predefined rules.

The configuration of the warnings could look like this:

WARN_FORMAT = "<issue><file>$file</file><line>$line</line><message><![CDATA[$text]]></message></issue>"

Possible warnings are:

Compound XXX is not documented.
Found unknown command 'NNN'
Member ... is not documented.
The following parameter of NNN is not documented:\n  parameter 'AAA'.
The following parameters of NNN are not documented:\n  parameter 'AAA'\n  parameter 'BBB'.
argument 'AAA' of command CCC is not found in the argument list of FFF.
parameters of Member NNN are not (all) documented.
return type of Member NNN is not documented.
unable to resolve reference to 'NNN' for XXX command.

The warnings are only plain text without any warning id.

Doxygen code creating the messages:
https://github.com/doxygen/doxygen/blob/master/src/message.h
https://github.com/doxygen/doxygen/blob/master/src/message.cpp