3

After installing SonarLint plugin for Eclipse (v2.0), the .project files in the workspace are changed! They are automatically extended by:

<buildCommand>
    <name>org.sonarlint.eclipse.core.sonarlintBuilder</name>
    <arguments>
    </arguments>
</buildCommand>

In our opinion it's a bug in the SonarLint plugin. As long as I don't extend a project by SonarLint-specific options the file .project should not be changed.

Can this problem be solved by means of any plugin options?

andreasgk
  • 673
  • 1
  • 12
  • 30

2 Answers2

2

In version 2.2 of SonarLint the .project file is no longer modified. The improvement was part of the ticket:

[SLE-80] - Replace SonarLint builder by a ResourceChangeListener

Lennart Schedin
  • 1,036
  • 1
  • 13
  • 24
0

The sonarlintBuilder is what make "on save" analysis possible. By default all projects are analyzed by SonarLint so this builder is added on all projects.

You can decide to stop automatic analysis for some projects: in project properties -> SonarLint -> Disable automatic analysis.

Julien H. - SonarSource Team
  • 5,212
  • 1
  • 19
  • 25
  • 1
    I can stop automatic analysis for a project but it's too late because the project file was already modified in the background. We have dozens of Java projects in the workspace. Now, after SonarLint plugin installation, all project files get modified! For our developers it's unacceptable. All project files come from the CMS and are at the beginning not checked out. – andreasgk Apr 15 '16 at 14:43
  • I don't understand why it is a problem: if you install SonarLint it means you want to use it right? It is not uncommon for plugins to add a nature or a builder to the projects so having a modification in .project file is expected. Would you advocate the old behavior: SonarLint disabled by default and only enabled manually on each project? – Julien H. - SonarSource Team Apr 18 '16 at 07:18
  • 1
    Disadvantages of the current plugin behaviour that were reported to me by our developers: 1. .project files may be read-only because not checked out from SCM. 2. Changed .project files cause automatic builds of other projects because of dependencies. 3. After changing .project files, all projects are automatically analyzed by SL plugin. If the workspace consists of hunderts of projects then after SL plugin installation and Eclipse restart you have an impression Eclipse is hanging. It would be good if SL could be configured explictly for every workspace. – andreasgk Apr 21 '16 at 14:03
  • 1
    I ran into the same problem. It is true that other plugins expose the same "rude" behaviour. Changing files, in particular typically versioned files, without explicit user consent is unfriendly. I disabled automatic analysis. – gnomie Apr 22 '16 at 10:08
  • It would be nice, if there was an option to disable this invasive behaviour. In my eyes only an explicit binding to a SonarQube project should trigger the modification of the .settings-files. For now, this is a showstopper for our team. – user871611 Jul 13 '16 at 13:39