Access syntax tree from custom serverside plugin?

Hello,

I’m interested in writing a SonarQube plugin for my organization which will gather a list of all Java class fields annotated with a specific annotation in the source code, and upload that list someplace.

I’ve written custom rules before, but never a server-side or compute-engine-side plugin. From what I was able to find, there are significantly fewer docs for writing these types of plugins.

I was wondering if anyone with experience writing server-side plugins could help answer this question: Can I access the syntax tree from a server-side plugin, or from somewhere other than a custom rule? How would you go about this?

Thanks,
Adam

Is there a way to pass an arbitrary context object from the scanner to the server? I could visit the fields I’m interested in from a scanner plugin, and then read that list from a server plugin if this were possible.

Hi Adam,

No I don’t think this is possible. See it this way: the Syntax Tree is built by the analyzers during the analysis in order to detect issues; it is not persisted in any way at the end of the analysis. By ‘analysis’, I precisely refer to the scanner-side execution (server-side Background Task in no way manipulates the syntax tree).

I would argue that this use-case does not correspond to what the SonarQube APIs are intended to help with. SonarQube is about detecting bugs/vulnerabilities/code_smells , and computing code-related measures. It’s open and offers APIs for you to extend that, When I read ‘gather a list of all Java class fields annotated with a specific annotation in the source code, and upload that list someplace’ I do not see the relation with code quality and/or bug detection, so trying to do a SonarQube plugin for that purpose might end-up a very frustrating effort (not what the product and its APIs are designed for).

Ultimately I would advise to still consider non-SonarQube approaches for fulfilling your use-case here.

1 Like

Hi Nicolas,

Thank you for your reply.

Since posting the question, I have started prototyping the extension as a scanner-side extension, and it is going well. It’s good to hear I’m on the right track in that regard.

As for the use-case, I left out some information in my question about how this translates into a Sonar rule. The idea is to write an extension which detects when certain fields in the source code are modified in such a way that breaks compatibility with a previous release, and add issues to those fields that do. Since Sonar rules on their own do not have awareness of the previous release, this is something I’m building into the extension.

I think I’ve found an approach which is working for me. Thanks again for the advice.

Best,
Adam