sonar-scm-svn auto-detection fails on Maven flat multi-modules project since Scanner for Maven 3.4

[Alix Lourme]

Hello,

Since Scanner for Maven 3.4, the sonar-scm-svn fails on SCM auto-detection on a Maven flat multi-modules project, when each module checkouted independently:

├───.myProjectRoot
│   ├───.svn
│   └───pom.xml
├───myProjectModule1
│   ├───.svn
│   └───pom.xml
├───myProjectModule2
    ├───.svn
    └───pom.xml

In this case, we can see in log:

[INFO] Execute project builders (done) | time=141ms
[INFO] Load quality profiles
[INFO] Load quality profiles (done) | time=141ms
[INFO] Load active rules
[INFO] Load active rules (done) | time=2715ms
[INFO] Load metrics repository
[INFO] Load metrics repository (done) | time=94ms
[WARNING] SCM provider autodetection failed. No SCM provider claims to support this project. Please use sonar.scm.provider to define SCM of your project.
[INFO] Project key: org.package:myProjectRoot
[INFO] -------------  Scan XXXX

If property -Dsonar.scm.provider=svn used on build, it works ; we can see on each module:

SCM provider for this project is: svn

Perhaps it is due to MSONAR-164 (Make flat project layout working out-of-the-box with SonarQube 6.6+) ; in this case a context.projectReactor().getRoot().getBaseDir() in a SonarQube plugin retrieves the "parent" directory of root project (=> Eclipse workspace or CI build working directory).

I understand that it is useful for SonarQube scanner (baseDir contains all modules), but there is no ".svn" directory in baseDir in this case.

Best regards

[Julien HENRY]

Hi,

We don't support multi-module projects made of multiple SCM projects. The SCM configuration is computed only once for the whole project.

The fact it was working previously was "accidental" (I guess SVNKit correctly get the .svn folder depending from where it is run).

Our recommendation would be to analyze each SVN projects as unique SonarQube projects.

++

Julien

[Alix Lourme]

Hello Julien,

Thanks for the reply.

Our recommendation would be to analyze each SVN projects as unique SonarQube projects.

I agree it can work technically ... but this is a Maven project with same lifecycle ... it is a non-sense :-(.

Flat Maven multi-module projects & SVN are perhaps "a little" outdated ... but it is not really a bad practice ; it is hard to switch this directories organization of many thousant projects when SonarQube is upgraded :-(.

I will try to find a workaround ...

Best regards

[Julien HENRY]

Hi Alix,

If this is the same project with the same lifecycle, how do you end up having one .svn folder per module, and no .svn folder at the root? How do you checkout this project? AFAIK there should be only one .svn folder at the root of your checkout.

Did I missed something?

++

Julien Henry | SonarSource

Developer

https://sonarsource.com

--
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/MmOuq1ivyvk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/b34c1898-e872-4bdb-9ccf-f2918f640b39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alix Lourme]

Hi Julien,

With Subversion, you have the both case depending the way your are doing the checkout.
And the way with one .svn by directory is better in some case, two sample ; with this structure (containing 2 lifecycle multi-modules projects):

[company-repo]/trunk
├─── myProject1Root
├─── myProject1Module1
├─── myProject1Module2
├─── myProject2Root
├─── myProject2Module1
├─── myProject2Module2


NB: It is better having a sub-repository trunk/branches/tags by project lifecycle (best practice), but multiple (multi modules) projects under same trunk could exist.

Under Eclipse (SVN perspective), multi-select myProject1Root & myProject1Module1 & myProject1Module2 and checkout, you have one .svn by directories.

Under CI tool (like TeamCity, my real use case), configure "[company-repo]/trunk" as VCS URL with some checkout filters (+:myProject1Root & +:myProject1Module1 & +:myProject1Module2) avoiding retrieve useless other (potential) projects (myProject2XXX in sample), you have one .svn by directories.

Best regards

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

[Julien HENRY]

If Project1 and Project2 are independent projects, why not using this layout?

[company-repo]/trunk
├─── /myProject1

     ├─── myProject1Root
     ├─── myProject1Module1
     ├─── myProject1Module2

├─── /myProject2
     ├─── myProject2Root
     ├─── myProject2Module1
     ├─── myProject2Module

So you could checkout /trunk/myProject1

Anyway, just force sonar.scm.provider to svn and it should be fine (or set scm URL in your parent pom). I don't expect many changes on svn provider side.

Julien Henry | SonarSource

Developer

https://sonarsource.com

To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/d3274fa2-4388-4f99-b56d-b032f538c89f%40googlegroups.com.

[Alix Lourme]

Hi Julien,

If Project1 and Project2 are independent projects, why not using this layout? [...] So you could checkout /trunk/myProject1

I agree this is better ... but changing the layout on many projects just for SonarQube v5 -> v6 LTS is not a minor impact.

Anyway, just force sonar.scm.provider to svn and it should be fine (or set scm URL in your parent pom). I don't expect many changes on svn provider side.

OK, I will force this property in a custom SonarQube plugin when ".svn" directory detected on directory where analysis is launched.

Best regards