Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

property 'sonar.cxx.coverage.reportPath' should be made using 'getStringArray' method. The SonarQube plugin using this property should be updated #1384

Closed
guwirth opened this issue Jan 10, 2018 · 1 comment · Fixed by #1568
Assignees
Labels
Milestone

Comments

@guwirth
Copy link
Collaborator

guwirth commented Jan 10, 2018

20:56:30 [sonar:sonar] Access to the multi-values/property set property 'sonar.cxx.coverage.reportPath' should be made using 'getStringArray' method. The SonarQube plugin using this property should be updated.

To be updated (see also #1381)

@guwirth guwirth added the bug label Jan 10, 2018
@guwirth guwirth modified the milestone: 0.9.9 Jan 10, 2018
@guwirth guwirth added enhancement and removed bug labels Jan 15, 2018
@guwirth
Copy link
Collaborator Author

guwirth commented Jan 15, 2018

https://groups.google.com/forum/#!topic/sonarqube/3JCtRo8r_Yc

With the move from Settings to Configuration, I'm trying to enforce some consistency between property definition, and property "use".

On server side and scanner side, there are some special treatments for multi-valued properties (in particular to support comma inside a value). This will work best when:

  • multi-valued property is declared as multi-value in the property definition
  • values are read using provided getStringArray() (and not get() + split yourself)

So when moving to use org.sonar.scanner.config.Configuration, a warning will be emitted when:

  • you read with get() a property declared as multi-valued
  • you read with getStringArray() a property not declared as multi-valued

For completeness @ Günter: SONAR-9478 , with related note in API changes documentation :

  • org.sonar.api.config.Configuration as a clean replacement of org.sonar.api.config.Settings. A warning will be logged when multi-valued properties are not properly declared/read using Configuration#getStringArray.

ivangalkin added a commit to ivangalkin/sonar-cxx that referenced this issue Oct 8, 2018
1. fixes SonarOpenCommunity#1384

Literaly all sensors derived from `CxxReportSensor` as well as `CxxSquidSensor`
use use the method `CxxReportSensor::getReports()` in order to access the
reporth paths. This method expects the `*.reportPath` property to be
a multi-value one. So fix the property access

* use `getStringArray()` method for parsing
* mark corresponding properties as multi-value

2. fixes SonarOpenCommunity#1376

While working on (1) I've found out, that the property
`UnitTestConfiguration.NUNIT_TEST_RESULTS_PROPERTY_KEY` is not public
accessible. This contradicts to the SonarOpenCommunity#1376.

On the other hand, if there should be no soupport for NUnit,
either the property must be marked as deprecated or the NUnit support
has to be removed completely. Please review.
ivangalkin added a commit to ivangalkin/sonar-cxx that referenced this issue Oct 10, 2018
1. fixes SonarOpenCommunity#1384

Literaly all sensors derived from `CxxReportSensor` as well as `CxxSquidSensor`
use use the method `CxxReportSensor::getReports()` in order to access the
reporth paths. This method expects the `*.reportPath` property to be
a multi-value one. So fix the property access

* use `getStringArray()` method for parsing
* mark corresponding properties as multi-value

2. fixes SonarOpenCommunity#1376

While working on (1) I've found out, that the property
`UnitTestConfiguration.NUNIT_TEST_RESULTS_PROPERTY_KEY` is not public
accessible. This contradicts to the SonarOpenCommunity#1376.

On the other hand, if there should be no soupport for NUnit,
either the property must be marked as deprecated or the NUnit support
has to be removed completely. Please review.
@guwirth guwirth added this to the 1.2 milestone Oct 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

2 participants