Sonar Initializer removal


(Jean-Christophe Voogden) #1

Hello,

I develop a SONAR plugin for a proprietary 4GL product (Adelia Studio). Adelia Studio stores program source not as text files, but in a binary format in a database.

Since SONAR 4.2 we used an Initialiser (org.sonar.api.batch.Initializer) to serialise program source code in text form and generate some metadata depending on rules profile configuration by directly accessing our repository…

Now that this functionnality has been removed in the latest versions (in 7.4+?), what is the proper way to get access to the SONAR project and profile definitions prior to scan to properly generate needed data ?

Regards,


(Julien Henry) #2

Hi @jcv

I removed Initializer since it was called once per module, and we are progressively moving away from modules.

The remaining extension point that can be used to initialize project structure is org.sonar.api.batch.bootstrap.ProjectBuilder. It is marked as deprecated because it allows too many things (like changing project structure, adding modules, …) in an unsafe way. My middle term goal is to identify all “valid” use cases (use cases we want to support) and probably introduce more specialized extension points.
In the meantime, you can still use it, it will not be removed.

The only question is

generate some metadata depending on rules profile configuration

in the ProjectBuilder, you won’t be able to get access to the ActiveRules. Can you give a bit more details about the kind of metadata you are generating, and how it is used during the analysis?


(Jean-Christophe Voogden) #3

Hello,

Thanks for your response.

I oversimplified things a bit. Adelia Studio is a Windows 32bits 4GL, generating multi-platform applications. It provides an integrated quality tool (for users wanting an integrated solution without third party products), written from start with SONAR compatibility in mind (it uses similar metrics and rules definitions, and has its own notion of "rule profile"). It is also expandable by users to define their own rules and metrics via an extension system.

Our SONAR plugin is really an interface over our own tool. Everything is computed by the Adelia own quality manager, the SONAR plugin duplicates the profile information and the generated data (metrics and rule violations).

What I called "metadata" is in fact all the information (generated source code, computed metrics and rules violations). The “Initialiser” format generated source code (xml) in a readable way and computes the metrics and violations (using JNI calls to the Adelia generation tools ATM).

So the problem is to pass the SONAR profile to our own tool to generate data accordingly to the SONAR configuration (rules activation and parameters). Aside from that, data could be generated separately by an ANT task for example.

Regards,


(Julien Henry) #4

What we tend to promote now for such integration is to run third party analyzer outside the SonarQube scanner lifecycle (could be a build plugin, like Ant task or Gradle plugin).
Then the only remaining extension needed in SonarQube is a Sensor to “import” the data.


(Jean-Christophe Voogden) #5

I was afraid of this. The main problem is that we will loose a part of the SONAR integration (mainly rule parameters) and we will have to make our users to change their procedure.

Is there an external API that could allow to read the profile definition ? REST service ? In this case I could write a maven plugin outside of SONAR to prepare the data before the sonar:sonar phase, while keeping profile configuration synchronized…

We are rewritting the plugin to remove the JNI interface so in short term the Initialiser will do just that.


(Jean-Christophe Voogden) #6

Or should we reverse the problem ? Creates a “per project profile” and inject it in the sensor ? Is that even possible ?


(Julien Henry) #7

There are REST APIs to fetch rules and quality profiles. This is what is used by SonarLint.


(Jean-Christophe Voogden) #8

ATM i cannot use the ProjectBuilder. An Adelia Studio project correspond to a SONAR module, we do not have contextual information at this point.


(Jean-Christophe Voogden) #9

I did not see your latest response. I think the right way to do it is to develop our own maven plugin for the data extraction phase, using the REST api to query profile information and ensure it is executed before the sonar phase.

Thank for your responses, regards.