Request for Feature: infer sonar.java.source when in doubt

[Victor Noël]

Hi,

Wouldn't it be possible to have a default value set for sonar.java.source that matches the version of Java used to execute the sonar scanner?

The justification would be that in case it is not known, it is maybe best to simply assume that the same version of Java was used to compile and to analyze the project.

What do you think?

Thank you :)

[Nicolas Peru]

Hi Victor, 

This can be a nice assumption but this is highly debatable (a lot of our users have a sonar setup different from their build). 

I have just a simple question for this : why would you need this ? 

Another approach we considered was to increase versions depending on language constructs we encounter during analysis (generics -> 5+, diamond operator -> 7+, lambda -> 8+, etc).

We have absolutely no clear plan for implementing this kind of feature as we don't see this lack as a problem, hence my first question : why would you need this feature ?

Cheers, 

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/f0246328-05c1-4fff-b941-d610a4b570a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

[Victor Noël]

Hi,

I made the assumption that people would do both compilation and analysis in a same go, so they would use the same version of the JVM, but it's true there is many ways to do it.

My need is more for ease of use: I configure Sonar in Jenkins only (i.e. I don't configure it in the pom of my projects when using maven) so I need to set this information for each of my project the Java version (while for the rest of the properties, it can be done using the options provided by Jenkins).
It will be very bothersome to do it for each of the hundreds of projects, some are not using the same version of Java, so I was wondering if this couldn't be inferred by Sonar…

Two other ideas:
 * to infer the version in Sonar Scanner: use the information stored in the class (see for example http://stackoverflow.com/questions/1096148/how-to-check-the-jdk-version-used-to-compile-a-class-file) even though I think it's the target version and not the source one... not sure).
 * to ease setup in the Jenkins Plugin: also populate this information when enabling the option "Prepare SonarQube Scanner environment" based on the JDK setup in the project!

I guess the important idea is to know the version used to compile the class, right?

The second idea would be perfect for me, but more generally, it would make sense to assume a version closest as possible to the one of the class.

Thank you!

Victor

[Victor Noël]

Actually, I'm re-opening this discussion, because I misexpressed my problem the first time I think:

I'm using the sonar-maven-plugin, and it should set this information based on the pom's configuration (I have maven.compiler.source set to 1.7), but it apparently does not (java 1.8 is assumed in the issues it seems).

See for example: http://jenkins.petalslink.com/view/3%20-%20Container/job/Petals%20Container%20-%20Microkernel/652/console, it says: [INFO] Configured Java source version (sonar.java.source): none

The page http://docs.sonarqube.org/display/PLUG/Handling+Java+Source+Version says "The feature relies entirely on the sonar.java.source property, which is automatically filled by most of the scanners used for analyses (Maven, Gradle).".

Victor

Le mercredi 27 avril 2016 08:50:20 UTC+2, Nicolas Peru a écrit :

[Julien HENRY]

Hi,

Depending on how you configure the property in your pom we may miss it:

https://jira.sonarsource.com/browse/MSONAR-128

Fix is planned for next version (no schedule yet).

++

Julien

[Victor Noël]

Excellent, thanks!