Sonar-Java 4.12 contains breaking change that kills legacy projects.

[Jan Nylund]

The Sonar-Java 4.12 plugin contains a change that `sonar.java.binaries` is required. This is a breaking change, since it actually kills any legacy analysis that does not have this setting added.

It doesn't seem possible to file issues on GitHub either, so I guess this is the only place to take the discussion.

I suggest that you revert this to a warning, and if it really needs to be enforced, it should be part of a Major plugin release. Already the tests for this PR shows it's a silly idea, since the workaround for passing tests is to set binary folder to src.

References:

- https://github.com/SonarSource/sonar-java/pull/1547

- https://docs.sonarqube.org/display/PLUG/Java+Plugin+and+Bytecode

[Michael Gumowski]

Hello Jan,

Sorry, but this probably won't be reverted at this point. SonarJava requires bytecode to work efficiently and properly, and it has been the case for years. With this change of behavior, we only enforced a configuration which was expected to be the normal one. Warnings in logs have also been printed regarding missing bytecode for ages. What result could you expect from an analyzer fed with only partial data? For that reason, we didn't considered to be significant enough to justify a major release.

Now, I can understand that some legacy project may start failings after the update, but it's unfortunately only a painful reminder that these project are poorly configured. The fact that we bypass this behavior in our own tests is irrelevant: this is not what is tested.

Regards,

Michael

--
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/efeb1dd8-b113-4915-b9eb-fa8caa83c90a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael Gumowski | SonarSource

Software Developer, Language Team
http://sonarsource.com

[ais...@gmail.com]

Hi,

It would be great if the scanners could provide this property automatically (where available). I use SonarQube Scanner for Gradle 2.5 with Gradle 4 and a moderately big multi-project build including multiple languages, and it took me hours to figure out why all our SonarQube issues silently disappeared as there was initially no error message or warning of any kind. (I eventually started removing language plugins to isolate the issue; removing all but SonarJava caused the scanner to give a unclear warning, and even then it took looking at the SonarJava 4.12 docs to understand what was happening).

Regards,

Ashton

[ais...@gmail.com]

Hi,

Sorry, on further investigation, it seems the SonarQube Scanner for Gradle 2.5 does try to set the property, but uses the deprecated (and wrong since Gradle 4.0) sourceSets.main.output.classesDir Gradle property as its default. This obviously needs updating, as it will break completely with Gradle 5.0

Regards,

Ashton Batty

[Tibor Blenessy]

Hello Ashton,

seems you are right, we already have ticket for this issue https://jira.sonarsource.com/browse/SONARGRADL-40 

Best regards

--
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/3074e71d-f648-46a9-a1d3-c8c10cba3408%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Tibor Blenessy | SonarSource

SonarJava Developer

http://sonarsource.com