Gradle SonarQubePlugin.getProjectKey doesn't return unique values

[mark_s...@dell.com]

Hi,

I asked a question at StackOverflow (http://stackoverflow.com/questions/34957615/gradle-sonarqube-run-duplicate-module-key-in-reactor).

When I examined the sonar properties file, it was clear that projects were indeed having duplicated sonar.moduleKey values.

There is a logic error in SonarQubePlugin.getProjectKey method.  This function is used to create the sonar.moduleKey (and sonar.projectKey) properties.

If I look at the method, it is assuming that the project name is unique across the project. This is an invalid assumption, consider the following valid Gradle projects:

• root project (group: com.foo.bar, name: bah
• folderA (implicit project, moduleKey: 'com.foo.bar:folderA')
• foo (real project, moduleKey: 'com.foo.bar:foo')
• folderB (implicit project, moduleKey: 'com.foo.bar:folderB')
• foo (real project, moduleKey: 'com.foo.bar:foo')
• Duplicate Module Key
• folderC
• foo (implicit project, moduleKey: 'com.foo.bar:foo)
• Duplicate Module Key
• someproject

There are multiple ways to make the moduleKey more unique.  The obvious one might be to change:

String name = project.getName();
String group = project.getGroup().toString();
return group.isEmpty() ? name : (group + ":" + name);

to:

String name = project.getPath();
String group = project.getGroup().toString();
return group.isEmpty() ? name : (group + ":" + name);

This would result in a longer, more unique moduleKey, such as: 'com.foo.bar:folderA:foo', which would at least be unique.  I don't know enough about how SonarQube uses the project/module keys to know if this would break anything, however.

In my case, I made a workaround that works with the existing v1.2 sonarqube gradle plugin:

def projectList = [
    ':integration:lib:messageformatter:plugins',
    ':integration:lib:action:plugins',
    ':integration:lib:pal:plugins',
    ':business:devices:plugins',
    ':integration:lib:elasticsearch',
    ':integration:lib:pal:customactions',
    ':integration:lib:tasks'
]

projectList.each {projectPath ->
 def projectToModify = project.findProject(projectPath)
 project(projectPath) {
  def newModuleKey = "com.dell.enterprise.common${projectToModify.path}"
  logger.quiet("Applying module key ${newModuleKey} to project ${projectPath}")
  sonarqube {
   properties {
    property 'sonar.moduleKey', newModuleKey
   }
  }
 }
}

Mark E. Scott, Jr.

[Julien HENRY]

Hi Mark,

Would you be able to produce a sample Gradle project to illustrate your example. I'm not sure to understand what you call "implicit" vs "real" project. In the meantime I have created the following ticket to track progress:

https://jira.sonarsource.com/browse/SONARGRADL-12

Based on your reproducer we would then think of a solution, the main issue is how to not break history for existing projects after changing the module key.

Anyway thanks for the feedback.

++

Julien

[Mark_S...@dell.com]

Dell - Internal Use - Confidential

I have added comments to the ticket, as well as attaching a zip file with a simple project that exhibits the behavior.

 

Regards,

 

Mark E. Scott, Jr.

Software Engineer

Dell | Global Large Enterprise Product Group

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/uHEtD3UfS2w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/4a1adb38-2023-4e22-8f28-d5fd8491c00a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Julien HENRY]

Thanks Mark!

To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.