RPG
RPG is available starting in Enterprise Edition.
Language-specific properties
Discover and update the RPG-specific properties in Administration > Configuration > General Settings > Languages > RPG
Source code extraction
In order to analyze your source code with SonarQube Server, you need to first extract it onto a filesystem. You can use your own tool or an open-source tool; SonarSource does not provide any connectors or source code extraction tools.
RPG source format
Depending on your extraction process, your RPG source files may include an extra margin on the left of the 80 columns used for code. This margin is in addition to the standard margin which takes up characters 1-5 in the 80-character source format (when "fully free-form" is not used). The extra margin is controlled through the sonar.rpg.leftMarginWidth
property. By default, it is set to 12, which is the size of the margin in an IBM “source physical file”. If your RPG source files do not contain such a margin, you should set sonar.rpg.leftMarginWidth
to 0
.
You can find an example file illustrating a 12-character margin in our sample project.
You should also make sure to set sonar.sourceEncoding
to the appropriate encoding. Please check the documentation of this property.
Free-Form Support
Free-form is supported for all kinds of specifications and SQL statements that exist in IBM i 7.4. Fully free-form code (starting with **FREE
) is also supported.
Custom Rules for RPG
To get started you can browse or download a simple plugin.
Prerequisites
- JDK 8
- sonar-rpg-plugin 2.0+
Creating a Maven project
You should first create a Maven project: re-using the pom.xml from the RPG example is a good start.
The following dependencies need to be defined in the pom.xml
:
sonar-plugin-api
to get access to SonarQube Server's APIs.sonar-rpg-plugin
to use the APIs of the RPG plugin.
Writing a custom rule
Each rule needs to be defined in a class which:
- Implements
com.sonarsource.rpg.api.checks.Check
. Instead of implementing this interface directly, the class can also extendVisitorBasedCheck
which makes it easier to target some specific parts of the analyzed source code. - Has an
org.sonar.check.Rule
annotation to define the key of the rule.
Navigating the syntax tree
The analyzed source code is represented as a tree structure. The top-most tree is an instance of ModuleTree
which has references to other trees. Some of the trees represent a group of RPG calculations (for example, an IF
group is represented as a tree that references the calculations which are executed when the condition is true), and some others represent expressions such as a + b
.
The instance of CheckContext
which is passed to the checks gives a reference to the ModuleTree
of the analyzed source code. The whole tree structure can be navigated from that object.
Most often, it's easier to extend VisitorBasedCheck
and to override one or more methods whose name starts with visit
, e.g. visitIfGroup
. That way, it's possible to define what should be executed when visiting some specific kinds of trees.
Creating issues
CheckContext
provides methods to create issues either at the file or line level.
Testing the rule
It's possible to write unit tests for custom rules using com.sonarsource.rpg.api.test.RpgCheckVerifier
. This utility class executes a custom rule against a given RPG test file. The RPG test file should contain comments denoting lines where issues should be expected:
- if the line ends with "// Noncompliant",
RpgCheckVerifier
expects an issue on that line. - if the line ends with "// Noncompliant {{my message}}",
RpgCheckVerifier
expects an issue on that line and checks that the issue message is "my message".
The example project contains an example test class and the associated RPG file.
Rules definition
One class should extend com.sonarsource.rpg.api.CustomRulesDefinition
: it should list the classes of the custom rules and use the SonarQube Server API to define the metadata of these rules: name, HTML description, default severity.
Plugin class
The entry point of the custom plugin is a class that lists SonarQube Server extensions. This list should contain the class created in the previous step.
Packaging the custom plugin
To package your custom plugin, the pom.xml should use org.sonarsource.sonar-packaging-maven-plugin
, as described in the documentation explaining how to build a plugin.
In the configuration for sonar-packaging-maven-plugin
, basePlugin
should be set to rpg
.
Building the Maven project will produce a JAR file that can be deployed to your instance of SonarQube Server.
Configuring plugins for analyzer loading optimization
By default, the loading of analyzers is optimized (see Improving performance), SonarQube Server will only download analyzers and third-party plugins for the detected languages before running an analysis.
When creating custom plugins, to prevent errors when projects are analyzed, you must use the requiredForLanguages
property in your plugin's pom.xml
file to specify the languages your plugin supports. Without this property, your plugin will be executed unconditionally during analysis, even when its language-specific dependencies are unavailable. See Plugin basics for details on this behavior and the requiredForLanguages
property.
Was this page helpful?