No Java with AutoScan! Planned?

SonarQube Cloud
1

Java does not belong to the list of supported languages )-;
And you say: “Non supported languages (Java, […]) will not be analyzed at all.”
Does “at all” means “never”? If so, could you explain this decision please (for sake of curiosity)?

2 Likes
2

The reason we currently don’t support Java (and other compiled language) is that our analyzers need the binaries (i.e. compiled sources) to provide relevant results. And automatically compiling any Java project (or other compiled language) is not a trivial task. So, we currently want to fully develop the feature (with proper UI/UX) for interpreted languages only.

AFAIK we might support Java in the future, so I wouldn’t say never but we don’t have a precise plan yet.

6 Likes
3

Thanks for the explanation. Is there a way to use the autoscan feature in combination with something like Gradle or Maven for projects that feature Javascript and Java? I ask because we initially set up the project using autoscan and would like to add Java analysis as well.

4

Hi Rob, welcome on this forum.

Building a Java project is usually not only a matter of running Gradle or Maven on a fresh environment. Builds require configuration, the most basic example being the JDK version to be used. Duplicating the configuration that is set on CI side (Travis, CircleCI or others) and running the build twice is not considered as a valid option.

Nevertheless it’s easy to activate analysis in your CI. You have two options:

  1. run scanner after the Gradle or Maven build
  2. or configure and run the Gradle or Maven plugins

I hope it helps.

5

Thanks, Simon. It sounds like what you are suggesting is running the Sonar task as part of our CI pipeline and disabling the Github analysis by renaming the properties file. Should we remove the project from Sonarcloud before the initial run using Gradle or is it fine to leave everything as is within Sonarcloud?

6

I forgot to mention that the project key should be added to your configuration (see sonar.projectKey). Keeping the key generated by Autoscan is enough for switching analysis to your CI. Value is displayed in the bottom-right of project dashboard, for example:
VoTT%20-%20Microsoft%202019-03-18%2022-40-56

7

Thanks again. One of the reasons we wanted to use the autoscan feature was because it allowed us to take advantage of the Github checks on PRs. We have other services we use that indicate issues with a PR so it fits in well. Is there any way to take advantage of the Github integration using Sonar as part of our CI pipeline instead of the autoscan feature?

8

Yes sure ! You just need to configure your CI to analyse your Pull Requests, and install the SonarCloud GitHup App on the GitHub organization which host your repositories (the installation is done automatically if you bind / or have bound your organization).

Hope it helps!

2 Likes
9

Thanks for the response. It sounds like you are saying that we should still see the SonarCloud Code Analysis check in Github PRs using this approach? I’m a bit surprised by this as we didn’t see that behavior when we had our repos set up using the Gradle Sonar task. In fact, that’s what motivated us to move to AutoScan. Perhaps we had something misconfigured or this functionality was added in the interim?

10

Maybe it was added in the meantime, Checks were introduced recently as you can see in the announcement.

11

Actually, it was because I wasn’t passing in the correct parameters to the sonarqube task.

Somehow I missed this the first time around. This post was put me on the right path:
https://blog.sonarsource.com/sonarcloud-loves-your-build-pipeline

3 Likes
12

Hello,
Is there any update for this issue? I’ve noticed a project which has results for its java codest:

However, I cannot make same thing for my java project.

13

Hello @Furkan_YY,

Could you go into more detail about the issue that you are having?