PMD/Checkstyle/Findbugs support in SonarLint

[fentavius]

I apologize if this was answered elsewhere (I did search on the topic but perhaps my google-fu is lacking) but I was wondering if support for some of the legacy rule engines , specifically PMD, Findbugs and checkstyle was planned for the future?

Great work by the way, this was a critical usage improvement that several projects I'm working on will adopt, perhaps even without support for the ~500 legacy rules we're current using and depend upon.

Thanks.
Chris

[Fabrice Bellingard]

Hi Chris,

we won't add support for any external engine - may it be for Java (Findbugs/Checkstyle/PMD) or for any other language. SonarLint can only work perfectly and super-fast if it embeds only our own analysers.

And thanks for the kind words!

Best regards,

Fabrice BELLINGARD | SonarSource SonarQube Platform Product Manager http://sonarsource.com

--
You received this message because you are subscribed to the Google Groups "SonarLint" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarlint+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarlint/d549a514-8954-436f-bf77-8410c565d922%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alix Lourme]

Hi,

@fentavius : SonarQube re-implements a lot of rules of these engines : Checkstyle / PMD / FindBugs => perhaps you could have a java quality profile according to your needs. The link between SonarLint and a specific SonarQube server is coming soon (for Eclipse ~1-2 months : SLE-26) => With that : "on the fly" analysis capacity ... with rules you wanted.

Best regards.

[fentavius]

Thanks for the quick reply Fabrice. I still think sonarlint will be usefull but it will be a harder sell to my team as we have historical and ongoing technical debt reports we publish to management based on the legacy external libraries supported in the qube.

Good to know that's the clear direction though. Thanks.

[fentavius]

Thanks for the reply Alix. I was aware that most (not all) of the pmd and findbugs rules have sonarjava plugin replacements unfortunately it's not really an option to just switch from our large legacy ruleset.

We have a large legacy codebase with something like 20k violations in 600k lines of code from 672 rules (all the javascript and maybe 5 or so are sonarjava, the rest are checkstyle, pmd and findbugs) that we use to publish technical debt statistics to management so it will be a significant effort to make a sonarjava/javascript only profile that produces similar looking information (rule configuration, replacement, plus the differences in behaviour between rules that work and those that don't) so it probably won't happen.

Unfortunately that leaves us on sonar eclipse (non lint) plugin and sonarqube <5.2 for the near and mid future. We'll probably only be able to use sonarlint for some incremental pre-commit analysis in addition to using the old sonar eclipse plugin.

Thanks for the suggestion though (I believe you were suggesting switching from deprecated rules to their sonarjava replacements, weren't you?).

BTW, I totally understand and was expecting this limitation. The linter is great despite this and I will at least use it personally even if I can't get the team on it!

Chris

[Alix Lourme]

Hi Chris,

I believe you were suggesting switching from deprecated rules to their sonarjava replacements, weren't you

Yes, but these rules are not necessarily deprecated, this is just "another implementation".

FYI, we have switch to SonarQube (in production) 2 years ago in my company. Previously we are used Checkstyle (mainly, a little PMD & Findbugs) in Eclipse with maven reports.
Some work has been done to have the same cover with the sonar-java plugin squid engine (promotion to SonarSource, some github pull-request on some rules, ...).

Currently we are using yet the checkstyle Eclipse plugin locally (the only "on the fly" analysis plugin with a custom profile), but as soon as SonarLint support the link with a SonarQube server, we will deploy it (=> company profile managed centrally, with the big profit of the sonar-java value added on some rules : symbolic execution, ...) ; and I will organize an event for the funeral of the Checkstyle plugin ^^.

SonarQube, with some commercial plugin (Sqale, Views) allow us to manage the quality of applications easily ; for techs guys and management/pilot people with some aggregation dashboards for all entities level in the company (~900 users, ~1200 projects/components, ~32 M LoC).

In conclusion, the pre-commit analysis is more efficient if supported and managed (for configuration) by a central platform.
I precise that I'm not a "pre-sale" of SonarQube, but it help us clearly to deploy a better quality process, even if the change of of previous tools must be accompagned.

Best regards

[Fabrice Bellingard]

On Tue, Sep 13, 2016 at 8:46 PM, Paulo Merson <paulo...@gmail.com> wrote:

Fabrice,

Hi Paulo,

 

Please allow me to be honest. It seems to me SonarQube is declaring war to checsktyle, PMD and Findbugs. And SonarLint is the first salvo of artillery.

In fact, SonarLint is not the first salvo of artillery in the competition with other analyzers - this started a few years ago already. 

Note that I'm talking about "competition" - which is good and even absolutely mandatory to sustain innovation, not "war" (we're peaceful guys you know, we don't like wars ;-)).

 

Saying that SonarLint can only work perfectly and superfast if these other analyzers do not run sounds like an insult to the developers of these other tools, but it's really an insult to our intellect.

I didn't mean to insult anybody with that statement. I simply meant that if we want to make sure that SonarLint will behave perfectly in all cases (and that's what we want), we must master as many piece of it as we can. And the good thing is that our core expertise is static code analysis! So for now, we plan to only support our own analyzers for that reason. I'm not saying that this won't change in the feature, I'm just saying that this is our current decision.

 

I really hope your team reconsider this 'declaration of independence' and think of the many organizations (like mine) out there that have invested a lot of time in polyglot static code analysis.
Remember, for 5+ years many people have created custom checks and custom rules using checkstyle and PMD. Back then, sonar (ergo sonarqube) did not offer an API for Java custom checks!
Now what should we do? Rewrite all custom checks using the new sonarqube custom check API for Java? What about PMD custom rules that parse XML or WSDL files?  If SonarLint can't run these analyses today, maybe next will be maven and jenkins? 

My humble suggestion/request: create a configuration option to skip other analyzers (non-sonarqube analyzers); set the default to skip the other analyzers; indicate in the documentation that enabling them can reduce significantly the performance of the code analysis. 

(I believe SonarQube is the best thing created for developers after JUnit. I'm a big fan. I'm thankful for all the hard work of sonar developers. But I was indeed sad to see this aggressive move in SonarLint.)

I perfectly understand your point of view Paulo, and I'm pretty sure I would advocate in the same direction if I was not PM at SonarSource. But in the same way we decided to not let SonarLint connect to a SonarQube server over the first year to concentrate on good technical and functional bases for the product, we won't let third party tools get into this world as long as we are not sure that this doesn't impact the quality of the product.

 

Paulo Merson, +1 in favor of diversity!

And thanks a lot Paulo for sharing your frustration and your feedback on this topic - I really do appreciate. :-)

 

To unsubscribe from this group and stop receiving emails from it, send an email to sonarlint+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarlint/9d41daa4-86a0-46da-a13a-643900211ad6%40googlegroups.com.

[Paulo Merson]

Fabrice,

Thanks a lot for the reply. 

"War" was too strong of an analogy indeed. But it's a pity that this community is at competition rather than collaborating. 

I still think SonarLint should have an option to run the third-party analyzers, but I fully understand that that option goes against the business goals for your project. 

In any case, a nice gesture toward the user community would be, at least, to keep compatibility of the old sonarqube Eclipse plugin with the new versions of the sonarqube server. But then again, probably the SonarLint business goals get in the way.

Thanks,

Paulo

[Fabrice Bellingard]

On Wed, Sep 14, 2016 at 4:37 PM, Paulo Merson <paulo...@gmail.com> wrote:

Fabrice,

Thanks a lot for the reply. 

"War" was too strong of an analogy indeed. But it's a pity that this community is at competition rather than collaborating. 

Even before Sonar(Qube) was created and entered the playground, community was already at competition: Checkstyle vs PMD vs Findbugs. ;-)

 

I still think SonarLint should have an option to run the third-party analyzers, but I fully understand that that option goes against the business goals for your project. 

In any case, a nice gesture toward the user community would be, at least, to keep compatibility of the old sonarqube Eclipse plugin with the new versions of the sonarqube server.

To be 100% honest with you Paulo, I'm not even sure this would be a gift to the community to maintain the old SonarQube Eclipse plugin: it was really not working well - most users were complaining that it was too way slow.

[Chris Gordon]

Paulo,

While I appreciate you rallying to my cause I'd like to give a counterpoint to my original request.

I actually DON'T want the sonar team to make efforts to support other plugins as I'd rather they focus on their own tooling. The reason: I want to see their limited resources focused on adding more functionality in an efficient way.

Our project is still tied to 3rd party rule sets including 670 pmd, findbugs and checkstyle rules, but that doesn't mean it has to stifle the innovation or even the usage of the newer platform.

As I've worked with now 5 different software teams (the benefit of being a consultant) over the past 5 years, I've realized that users of sonar (and codepro), at least in my experience get too hung up chasing rules stats and they forget the purpose of static code analysis: to provide efficient, quick and automated code review feedback BEFORE the code gets too far into the development process. Sonarqube and other static analysis tools simply provide advice. That's it. How you choose to react to that advice is a team decision having nothing to do with sonar or even with static analysis itself. Sonarqube is just a piece of software that replaces a code reviewer with a deterministic set of decisions. On any team, how do you normally react to code review advice? Some teams will not allow it out to production until all items are fixed. Others (the most common case IMO) pick and choose what advice to follow. Some code review recommendations are just personal preference. The stats reports serve the same function.

I realized this when I saw the team making ridiculous changes to the code just to get sonar violations to go away. This isn't the goal.

For anyone tied to legacy rules I'd highly recommend the following:

1) continue using sonar with your existing pmd,findbugs and checkstyle rules if it's too hard to move off them, perhaps keep them in the main continuous integration build and continue business as usual.

2) if you see value in the newer versions of sonar, want to use sonarlint, etc but don't want to break your existing sonar results, stand up a 2nd sonar instance with the new ruleset that builds off of completed tagged builds out of band from your normal continuous integration platform. You could even do it less often. The only cost to this is the minimal effort to set up a 2nd domain, the cost of cpu and storage to host that 2nd audit, and the complexity of having 2 sets of "advice". This complexity can also be managed in different ways by narrowing the access to key members or doing a transition, or adding it as a minor final pre-commit step in the process. The point is, the cost is negligible.

3) if your team is choosing a direction where they want to migrate off the dependency on the pmd and/or findbugs and/or checkstyle rules, then for item 2 start from the original ruleset you had that specified the "legacy" rules and slowly convert deprecated rules over until the stats are close enough to "switch". In the end, remind the users that when making the switch the code hasn't changed. If it has problems, it will continue to have those same problems. The visibility of problems with the code is all that has changed. If you have management depending on sonar reports to track team stats, then give them a picture at cutover, that the report at that time with sonar 4.5.x with pmd/checkstyle/findbugs is equivalent to the sonarqube 6.0 with sonarjava only rules. If management is using the sonar stats properly then they shouldn't be paying attention to the particular number or what rules those numbers come from, they should be paying attention to the trends those numbers have and what areas they are in. They can get the same value even with a cutover to a new set of numbers.

Our team is just now starting to use a 2nd platform, sonarlint cli with just senior developers so that we can insulate the larger team of weaker junior developers from the disruption to the development process of switching rules, sets, servers and eclipse plugins. Our continuous integration build will continue to use the old rules, most developers use the old eclipse plugin and continue as usual, and management looks at the old sonar stats. Only the development leads will be using the new ruleset to augment their code reviews. The new ruleset needs

Also, it'd be good to tone down the verbage a bit. While there are paid staffers at sonarsource there is definitely an opensource aspect to this and at the very least they're sharing their value freely, it'd be good to keep this in mind when spelling out "demands" for functionality. (sorry, I had to say it)

Just my 2 cents after having struggled with the the team's heavy dependency on the legacy version of sonar combined with additional work with other teams using it more lightly in their process.

Chris