Log4Mike

Since I have used Maven a lot over the years, I know my way around Maven. However I encounter a lot of people in projects that just know a few commands (mvn clean  install) by head and do not know how maven works or how to add and use functionality within Maven. Since there is a very good maven book (for free) from Sonatype, I will not get into the way Maven works, but I will focus on some practical tips to add functionality to your build.

Code quality monitoring
Focus of this part in the series is to monitor the code quality. In most enterprise projects with multi-module maven projects, the code quality is monitored using tools like PMD and Checkstyle. To include these into your build is easy enough, but escpecially when you want to encorporate a custom configuration and manipulate the what, how and when the code is tested, there seems to be missing some information.

When we define coding conventions using checkstyle and pmd configurations, it is a best practice to create a separate module for your project that includes those xml files in the src/main/resources of that module. That way all modules can use the same configuration.

Checkstyle

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-checkstyle-plugin</artifactId>
	<version>2.2</version>
	<dependencies>
		<dependency>
			<groupId>nl.mikoosoft.customer.project </groupId>
			<artifactId>build-tools</artifactId>
			<version>${project.version}</version>
		</dependency>
	</dependencies>
	<executions>
		<execution>
			<id>checkstyle-code-verification</id>
			<phase>compile</phase>
			<goals>
				<goal>checkstyle</goal>
			</goals>
			<configuration>
				<configLocation>customer-checkstyle.xml</configLocation>
				<failsOnError>true</failsOnError>
				<consoleOutput>true</consoleOutput>
				<encoding>utf-8</encoding>
				<excludes>**/nl/mikoosoft/customer/generated/**/*</excludes>
			</configuration>
		</execution>
	</executions>
</plugin>

Note that you can specify the encoding used to read the source files, overriding the settings of the Treewalker!

It is also very important to check which version of Checkstyle you are using. The new version 5.1 is not compatible with the previous version 4.4. You might encounter the same problem when you load your 4.4 configuration into the eclipse checkstyle 5 plugin. So be aware to choose one and preferably the latest. Do note that when you are using Sonar, you have to have Sonar 2.0 to be able to use checkstyle 5.
PMD
PMD is another static code analysis tool, which can support you in the review process. Personally I use PMD especially for monitoring the complexity of my code. Cyclometic complexity and Class Fan-out being my favorites. The good thing about PMD is that you can tweak the ruleset to enforce your coding guidelines. By setting the level at which you want to fail the build you can enforce people to adhere to the standards.

 <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <inherited>true</inherited>
                <artifactId>maven-pmd-plugin</artifactId>
                <dependencies>
                    <dependency>
                        <groupId>nl.mikoosoft.customer.project</groupId>
                        <artifactId>build-tools</artifactId>
                        <version>${project.version}</version>
                    </dependency>
                </dependencies>
           </plugin>
           <executions>
                    <execution>
                        <id>pmd-codestlyle-verification</id>
                        <phase>verify</phase>
                        <goals>
                            <goal>check</goal>
                            <goal>cpd-check</goal>
                        </goals>
                        <configuration>
                          <targetJdk>1.5</targetJdk>
                          <!-- Set the priority on which you want to let the build fail! -->
                          <minimumPriority>2</minimumPriority>
                          <rulesets>
			      <ruleset>customer-project-pmd.xml</ruleset>
                          </rulesets>
                            <excludes>
                                <exclude>**/src-gen/*.java</exclude>
                            </excludes>
                          <verbose>true</verbose>
                          <aggregate>true</aggregate>
                        </configuration>
                    </execution>
           </executions>
    </plugin>

Sonar

To monitor the code quality there is this wonderful open source tool called Sonar. It is easy to deploy and integrate into your already available continuous integration environment.
After building a project with maven, you can publish it to sonar using the sonar plugin:
mvn sonar:sonar
.

By configuring the plugin using a profile (see the example below), we are able to manage which modules are being analyzed by the Sonar installation.

<profile>
	<id>sonar</id>
	<properties>
		<sonar.jdbc.url>jdbc:oracle:thin:@database.mikoosoft.nl:1521:SONAR</sonar.jdbc.url>
		<sonar.jdbc.driver>oracle.jdbc.driver.OracleDriver</sonar.jdbc.driver>
		<sonar.jdbc.username>sonar</sonar.jdbc.username>
		<sonar.jdbc.password>${sonar.db.password}</sonar.jdbc.password>
	        <sonar.host.url>http://localhost:9000/</sonar.host.url>
	        <!-- list all modules that do not need java code analysis -->
	        <sonar.skippedModules>project-generated-content,project-build-tools</sonar.skippedModules>
	</properties>
</profile>

Especially the skippedModules setting is one that speeds up the process. Why should we have components in the overview that do not have any code to analyse in it? So skipping those makes the build faster and our overview of components cleaner.

So far the quick tips for using code quality checks in an enterprise maven project. Next in the series will be how to use plugins like:

• eclipse
• versions
• …

No related posts.