Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-1444

SonarLint for Eclipse - Drop the concept of module


    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Fix Version/s: None
    • Labels:



      As described in MMF-365, we’ve decided to stop supporting modules in our ecosystem: SonarQube, SonarCloud and SonarLint.
      SonarLint for Eclipse must be ready to properly work without modules before those ones disappear from SonarQube and SonarCloud.


      From the user point of view, the change should be as much as possible seamless:

      • After the upgrade, when the user opens a project with modules / a module, SonarLint will invalidate the storage (based on the version if was build for) and will require an update of the binding.
      • From there, SonarLint should be able fetch the list of remote files and to use an heuristic approach (relying for example on the longest file suffix) to map local files with the ones in SonarQube.

      We expect to use the same logic than the one used in IntelliJ (MMF-1386).

      The main difference here is that the binding process needs to be adapted:
      Currently, for a multi-modules project, the user needs to manually bind each project module to the module in SonarQube.
      Even when modules are still present in the server, users should not have to bind individually each module in their IDE. Now that modules will disappear from the server side, modules should be associated to the remote project.


      Create/edit binding
      • For modules that part of a same project, users will only have to select the project analyzed on the SonarQube/SonarCloud. No need to select remote modules anymore.
      • Automatic binding will be executed by default and will suggest as much as possible a remote project. The button will disappear.
      • In addition to the possibility to select and bind a list of modules from the Package Explorer, SonarLint will now give the possibility to create a new binding at the end of the server connection wizard and from the SonarQube servers window. The first step will then be to select the local project/modules to bind.

      Create a new binding:

      • Case 1:
        1. Right click and select several modules in Package Explorer
        2. Choose an existing SonarQube / SonarCloud connection (or create one)
        3. Select the remote project (or simply validate the suggested one).
      • Case 2:
        1. At the end of the creation of a SonarQube / SonarCloud connection, choose to create a binding
        2. Select local project/modules in a list. Only modules part of a same project can be selected.
        3. Select the remote project
      • Case 3:
        1. Right click in the SonarQube servers window and choose to create a binding
        2. Select local modules in a list
        3. Select the remote project

      Edit an existing binding:
      The process will also be modified accordingly. It will simply offer to select once again the remote project.

      This will be the opportunity to clearly distinguish SonarQube from SonarCloud in the configuration. And the first change could be to rename the SonarQube servers window into SonarLint connections.

      Upgrade existing binding
      • When users upgrade SonarLint, they will be asked to refresh the storage.
      • To be able to automatically upgrade old bindings, SonarLint needs to know the key of the remote project. But this information is available starting SonarLint 3.3. The upgrade from SonarLint <= 3.2 (released July 2017) will log an error explaining that the binding can't be upgraded and that it needs to be created again.


          Issue Links



              • Assignee:
                christophe.levis Christophe Levis
                christophe.levis Christophe Levis
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: