PMD and Maven

After explaining how to use PMD with NetBeans in this post, let me describe how we can directly run PMD using Maven, without the help of an IDE plugin.

We can have two different approaches:

• invoking the PMD plugin for Maven.
• using Maven site feature.

First approach. Add the following lines to the project pom (in the build/plugins section):

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-pmd-plugin</artifactId>
  <version>3.0.1</version>
</plugin>

(Of course, maven-pmd-plugin version can vary. See here for last updates).

PMD can be invoked from the command line with the following:

mvn pmd:pmd

which will create a file named target/pmd.xml. XML is the default output format but it can be changed with the format configuration option.

The file contains all violations detected by PMD in all source files found in the project. Test files are not checked in the standard configuration.

By default, only rules from the following rulesets are checked by PMD: java-basic, java-imports and java-unusedcode. We will see later how to control which rules and rulesets should be checked.

In the second approach, PMD is invoked during the Maven site command which is a reporting command. In this case the PMD plugin definition should be placed inside the reporting/plugins section of the project pom.

<reporting>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jxr-plugin</artifactId>
      <version>2.3</version>
    </plugin>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-pmd-plugin</artifactId>
      <version>3.0.1</version>
      <configuration>
        <targetJdk>1.6</targetJdk>
        <rulesets>
          <ruleset>pmd_rules.xml</ruleset>
        </rulesets>
      </configuration>
    </plugin>
  </plugins>
</reporting>

Note: the jxr plugin is useful for source code analysis. The reporting section usually has more plugins that the two shown in the examples.

Here the PMD plugin has been configured with a couple of important parameters: the Java version (targetJdk) and the set of rules and ruleset to be used (rulesets/ruleset).

My usual approach (described in the PMD in NetBeans post) is to define a custom list of rules and rulesets to be checked by PMD. With the Maven plugin we can use the same XML file used to generate the jar file for EasyPMD plugin.

We will have the same check results from NetBeans + EasyPMD and from Maven. Very good.

I usually save the custom rules file in the root of the project with a name like “pmd_rules.xml”. Not so smart name but easy to understand. Of course, it is versioned together with the project files.

Being versioned and saved in the repository let us share exactly the same PMD setup among all development team members. In the pom we have specified a relative path so we will not have problem to access it from different project installation paths.

If the project is multi-module with a parent pom as top dir and the modules in subdirs, I change the configuration as following:

<rulesets>
  <ruleset><strong>..\</strong>pmd_rules.xml</ruleset>
</rulesets>

so running mvn site (or mvn pmd:pmd) on a module will work. Only mvn site on parent pom will not work (but this is less important).

The two approaches I described are not exclusive and they can both be used in the same project. Just remember to have the same configuration in the two pom locations (build/plugins and reporting/plugins).

 

PMD in NetBeans: the EasyPMD plugin

PMD is a powerful source code quality checker which analyze our code and report bad coding habits, failures to respect naming conventions, inefficiencies and many others.

PMD has an internal list of rules to be checked. Rules are divided in sets. Each set contains several rules.

For example the “Comments” set includes all rules related to code comments.

PMD rules sets are documented here.

On my opinion a PMD rule violation should be intended as a suggestion to better check the code to be sure that the offending code line is really what we want to have. Often PMD is right to say the line should be fixed or at least improved.

In NetBeans PMD is enabled by the EasyPMD3 plugin available from NetBeans plugin area and from the plugin home page ( http://gianlucacosta.info/software/easypmd/ ).

Note: There is an enhancement request to introduce native PMD support in NetBeans, like what has been done with FindBugs.

One very important point to remember is that EasyPMD (and so PMD) is controlled by the “Action Items” window settings. Just click on the “Action Items” window filter icon and check that EasyPmd notifications are enabled. If not enabled,PMD will not check the code.

When enabled, PMD checks Java code and

• reports in the “Action Items” window all rules violations
• marks as a blue circle the lines in the open editor window that contain a rule violation

In the above picture, PMD reports that the field callCount is initialized to zero but this is a meaningless operation because zero is the default value for numeric fields. Actually this initialization will cost us few cpu cycles.

This is the PMD “RedundandFieldInitializer” rule belonging to “Optimization” rule set but there are many others.

Some PMD rules conflict with NetBeans hints because they check the same situation.

The processFindForm() method in the picture reassigns one of its parameter (owner); PMD reports it at line 86 while NetBeans at line 106.

I usually disable the PMD rule if there is an equivalent NetBeans hint, also because some NetBeans hints give us the possibility to fix the problem with a dedicated refactoring (but not the one in the picture). PMD is an pure analyzer so it does not perform any change in the code.

There are several rules and rules sets available in PMD but not all of them are relevant for us. For example the “Android” rule set is of course not interesting for Java EE applications.

Thankfully we can select rules set and single rules we want PMD to check.

EasyPMD give us two approaches: select the rules sets to use but not the single rules or full freedom in rules and rule sets selection.

The first approach can be done with the EasyPMD UI interface (Tools –> Options –> Miscellaneus –> EasyPmd3):

The list in the picture contains all rules set we want PMD to check. Single rules can be included or removed with the “Add Standard” and “Remove” buttons.

The alternative solution (full freedom) requires a preliminary activity: to prepare a jar file with the PMD rules set and rules we want to be checked. Detailed instructions to prepare the rules jar can be found here.

The basic idea is to create a xml file with contents like the following:

<?xml version="1.0"?>
<ruleset name="Custom ruleset" xmlns="http://pmd.sourceforge.net/ruleset/2.0.0">
<rule ref="rulesets/java/basic.xml"/>
<rule ref="rulesets/java/comments.xml">
    <exclude name="CommentSize"/>
</rule>

In the fragment above, I selected the complete “basic” rule set and the “comments” rule set except the “CommentSize” rule.

Source and jar file I use can be found here

Once the jar file with rules has been created, we instructs EasyPMD plugin to use it:

The rules jar is also useful to share PMD rules across the development team. The jar file can be placed in a shared area and all team members can refer to it in their (local) EasyPMD configuration.

Checking JavaScript in NetBeans

NetBeans 7.3 has introduced an improved JavaScript support, including a wider support for JavaScript code checks. It is also possible to install a JSLint plugin for stronger code checking.

Let’s start with NetBeans native capabilities. In the Tools -> Options -> Editor -> Hints we can find all NetBeans code quality checks, divided by language.

The following picture shows the JavaScript checks:

In the following picture we see how the NetBeans JavaScript hints work:

This is nice feature to have so we can fix the errors while we are coding. Unfortunately the NetBeans JavaScript checks are limited (in number) and we should use an external plugin to enforce our code checking rules to our js files.

JSLint is the reference JavaScript quality checker. A good JSLint plugin for NetBeans is available here.

To install it in NetBeans, juts follow this simple procedure:

1. Download the plugin on the PC

2. Open the Plugin window in NetBeans (Tools -> Plugins) and click on the “Downloaded” tab.

3. Click on “Add Plugins” and select the downloaded file.

4. Press “Install” to start JSLint plugin installation.

After installation, we can go back to our file and check it now with JSLint. Open the context menu (right mouse click) and select “JSLint”. In the Action Items window, we find all errors detected by JSLint on our file.

As we can see in the picture, JSLint is more restrictive than NetBeans, showing more errors (3 in our small example). For the complete and reference list of JSLint checks please refer to the JSLint author page.

If the Action Items list contains errors on other files in the project and in particular on libraries files (like jQuery and Bootstrap js files) we can easily filter out them. We can create an Action Item Filter as shown in the following images:

JSLint plugin configuration can be found in Tools -> Options -> Miscellaneous -> JSLint (tab). The options set on this page are valid for all JavaScript files in the project. In the next picture, the configuration I usually use in my projects:

Basically I limit line length to 80 characters and define window as global variable.

File specific settings can be defined as follows:

/*jslint sloppy:true */
/*global window */
function myFunc(txt) {
window.alert(txt)
}

The /*jslint contains JSLint configuration parameters while /*global defines implicit global variables (defined outside the current file). Important: there should be no space between the asterisk and the words jslint and global so take care that NetBeans formatting will not try to format Javascript comments.