Offline mode of Sonar Scanner for Maven

[CSchulz]

Hello,

I have recognized that the offline mode of Sonar Scanner (for Maven) was removed, see https://jira.sonarsource.com/browse/SONAR-6577?jql=text%20~%20%22offline%20mode%22 and https://jira.sonarsource.com/browse/SCANNERAPI-155.

Is there any reason why it was removed? The issue states that the code is removed because lint has its own core, but it seems that there is no offline mode either.

I was a big fan of the offline mode, because we could include the sonar scan in our maven build and it doesn't matter if I am on travel or in office.

[Julien HENRY]

Hi,

I'm very sorry for this confusing stuff. This feature was implemented before we decided to develop SonarLint as a dedicated product. We can say it was an experimental attempt to implement what SonarLint is doing now.

Now our position is clear:

  - Scanners are used to publish on SonarQube (so there is probably no reason for a developer to use them on its box)

  - SonarLint is the tool for developer

SonarLint works perfectly offline, you should definitely give a try.

++

Julien

[CSchulz]

Hello Julien,

thanks for the fast response.

SonarLint has no support for quality profiles.

But I have found out the stuff removed from sonar-scanner-api is part of sonar-batch and sonar-home. So I can use them to implement the feature in the maven plugin.

The idea is to run the analysis every build f.e. on Jenkins but publish only one time per day (or changed the way how the stats are generated? There was a statement to run the analysis in the same period to get correct stats years ago).

The normal analysis without publishing should break the build, if a quality gate is injured to prevent getting bad artifacts into our repository.

[Julien HENRY]

Le mercredi 27 avril 2016 14:51:06 UTC+2, CSchulz a écrit :

SonarLint has no support for quality profiles.

In connected mode you have same quality profiles than on your server. SonarLint for CLI is not yet having this feature but it will come.

 

But I have found out the stuff removed from sonar-scanner-api is part of sonar-batch and sonar-home. So I can use them to implement the feature in the maven plugin.

It 's still there for backward compatibility but it will be removed at some point.

 

The idea is to run the analysis every build f.e. on Jenkins but publish only one time per day (or changed the way how the stats are generated? There was a statement to run the analysis in the same period to get correct stats years ago).

This statement is no more valid. You can publish many time per day (but publishing for each commit may be costly depending on your workflow / project size).

 

The normal analysis without publishing should break the build, if a quality gate is injured to prevent getting bad artifacts into our repository.

How do you manage accepted issues (or false positive)? We found that breaking unconditionally the build was not convenient. We prefer to try catching 90% of new issues using SonarLint with a best effort approach, then have a safety net using pull request analysis before merging in the master where SonarQube publish analysis is executed.

++

Julien

[CSchulz]

The idea is to run the analysis every build f.e. on Jenkins but publish only one time per day (or changed the way how the stats are generated? There was a statement to run the analysis in the same period to get correct stats years ago).

This statement is no more valid. You can publish many time per day (but publishing for each commit may be costly depending on your workflow / project size).

Thats the reason to run only in analysis mode and not publish mode.

 

 

The normal analysis without publishing should break the build, if a quality gate is injured to prevent getting bad artifacts into our repository.

How do you manage accepted issues (or false positive)? We found that breaking unconditionally the build was not convenient. We prefer to try catching 90% of new issues using SonarLint with a best effort approach, then have a safety net using pull request analysis before merging in the master where SonarQube publish analysis is executed.

I was expecting that false positives are synced with the server and accepted issues needs to be fixed before they can be removed. Otherwise you could change the "settings" to say accepted issues doesn't count.

The PR workflow only works if you have feature branches and similar.

[CSchulz]

I have started some time ago a similar discussion https://groups.google.com/forum/#!topic/sonarqube/UlrmcWGgaw4 describing the use case.