SonarQube Scanner for Gradle - multi-module project with src in root

[jakub...@adspired.com]

Hi!,

I'm getting such a warning:

:sonarqube

/!\ A multi-module project can't have source folders, so '/path/to/proj/grails-app/services' won't be used for the analysis. If you want to analyse files of this folder, you should create another sub-module and move them inside it.

/!\ A multi-module project can't have source folders, so '/path/to/proj/grails-app/controllers' won't be used for the analysis. If you want to analyse files of this folder, you should create another sub-module and move them inside it.

...

...

and discovered this thread: https://discuss.gradle.org/t/how-to-apply-sonar-runner-to-multi-project-hierarchies-with-code-in-the-root-project/7369

Does this limitation still exist? 

I'm using Gradle 3.5 with plugin 2.4 and SonarQube 6.3.

Majority of my src code is in the Gradle root module (it's a Grails app). 

Does it mean I cannot analyse with the Gradle task? 

Moving the root module into a sub-module is actually out of question. 

What options do I have?

Kuba

[jakub...@adspired.com]

Sorry, for spamming but this is a huge blocker for me right now.

What I've tried so far :

* detaching sub-modules - for the analysis run I wanted to convert the multi-module project into single-module an execute it additionally - doesn't work since the sub-module deps are missing

* creating an artificial root module that includes the current one and adding some configuration around (just to run the analysis)- sounded like a great idea but the building goes crazy since the module dependencies paths are now incorrect (dependant on the path to root project `:module1` is now `:fakeRoot:module1`)

* copy the src to a fake sub module for the analysis run - also sounded like a good idea since I'm relying only on the static analysis of files but then I realised that the file paths will be incorrect when a violation is raised (I'm using GH PR analysis runs to mark violations in src)

* creating fake modules in all directories where source is defined - that would require a lot of gradle code with possibly duplicated build files - I abandoned this idea

Do you guys have any other idea how to trick Gradle to analyse my root module?

Kuba

[jakub...@adspired.com]

I have found this example in the official project repo: 

https://github.com/SonarSource/sonar-scanner-gradle/tree/master/integrationTests/src/test/resources/multi-module-source-in-root

but this is also affected by my issue

[Julien HENRY]

Hi Kuba,

This should be fixed by upcoming SonarQube 6.4 (first release candidate will probbaly be published next week). Still I didn't test with a real life use case on Gradle. Do you know if there is a Grails template somewhere I could use?

https://jira.sonarsource.com/browse/SONAR-6724

++

Julien

[jakub...@adspired.com]

Wow, if this would be fixed I would be very happy. 

I'll happily test an release candidate on my project.

I'm not aware of any templates but the project I found on GH: https://github.com/SonarSource/sonar-scanner-gradle/tree/master/integrationTests/src/test/resources/multi-module-source-in-root seems to be a good example. 

It contains source in root module so if it's analysed we are good!

PS.

I was under impression that it was a Gradle plugin limitation not SQ itself?

Kuba

[Julien HENRY]

Le mardi 9 mai 2017 14:15:08 UTC+2, jakub...@adspired.com a écrit :

Wow, if this would be fixed I would be very happy. 

I'll happily test an release candidate on my project.

Keep an eye on this list then ;)

 

I'm not aware of any templates but the project I found on GH: https://github.com/SonarSource/sonar-scanner-gradle/tree/master/integrationTests/src/test/resources/multi-module-source-in-root seems to be a good example. 

This one works fine on SQ 6.4:

 

I was under impression that it was a Gradle plugin limitation not SQ itself?

Nope, the project layout built into all pieces of SonarQube was inherited from Maven, were a module can't be an aggregator and have source folders. We started to remove this limitation since a few versions, and it is finally done with 6.4.

[jakub...@gmail.com]

Hey,

 just wanted to let you know that I've tested the SQ 6.4 RC2 and it works great! 

Multi module projects with src in root are now supported!

PS.

Not sure how RC should be tested but the dist didn't contain any plugins and the plugin page was not listing any... 

I've copied those from SQ 6.3 and apart from one, all worked fine!

[Julien HENRY]

> Multi module projects with src in root are now supported!

Cool! Thanks for the feedback!

> Not sure how RC should be tested but the dist didn't contain any plugins and the plugin page was not listing any... 

Like any fresh SonarQube installation, initially the folder extensions/plugins is empty. Some plugins will be automatically copied during first server start. Is it the case?

The fact no plugins are listed in the update center is expected (at least it is an old well known issue of release candidates and the way we manage the update center metadata).

[jakub...@adspired.com]

Like any fresh SonarQube installation, initially the folder extensions/plugins is empty. Some plugins will be automatically copied during first server start. Is it the case?

I started the 6.4RC as a standalone instance with a db copy from 6.3. I guess it cannot copy anything because id doesn't know from where. 

I've copied the extensions/plugins and extensions/downloads manually to 6.4RC and apart findbugs plugins (was throwing Caused by: java.lang.ClassNotFoundException: org.sonar.api.web.CodeColorizerFormat) everything went fine. I had to copy those plugins because I'm using github integration and without them I wasn't able to login via oauth or run the PR analysis.

Thanks again!