Reducing the pain of a release process

Who never crack down during a release process? Despite several tools ease the process; it’s generally a nightmare.

Why? Because of the number of task to execute during the process: the product has to be deeply tested before the release, then license/notice files have to be checked as well as license header, the release candidates artifacts have to be created, deployed, signed, don’t forget the release note, and to update the documentation…

So, I recently discover two maven plug-ins reducing (a little) the pain. They automate two checks: license headers and the code style consistency.

First the checkstyle plug-in (http://maven.apache.org/plugins/maven-checkstyle-plugin/) checks that your code is consistently formatted. It is, in my opinion, a critical aspect. So, diving into an unknown code consistently formatted is really easier. Using the plug-in is quite simple. Add the following plug-in configuration in the build section of your pom file:

<plugin>
<groupid>org.apache.maven.plugins</groupid>
    <artifactid>maven-checkstyle-plugin</artifactid>
    <configuration>           
        <enablerulessummary>false</enablerulessummary>
        <violationseverity>warning</violationseverity>
        <configlocation>http://felix.apache.org/ipojo/dev/checkstyle_ipojo.xml</configlocation>
    </configuration>
</plugin>

The ‘violationSeverity’ attribute sets the severity level from which the project build failed. So, if the code format breaks a rule with a level superior or equals to the set value, the build process failed. (Check levels can be set in the checkstyle file). The ‘configLocation’ attribute specifies the checkstyle file to use (containing the format rules).

So, once your project has the correct configuration, just launch the following command:

mvn checkstyle:check

to check if your project doesn’t break your format. If executed on a multi-module project, each module is checked (each module need to be configured).

So, thanks to this plug-in, checking the code format consistency is quite simple and can be automate during your project build process.

The second plug-in is the RAT plug-in (http://mojo.codehaus.org/rat-maven-plugin/). RAT (http://incubator.apache.org/rat/), is a tool to improve accuracy and efficiency when checking releases. It is heuristic in nature: making guesses about possible problems. It will produce false positives and cannot find every possible issue with a release. It reports require interpretation, but can also be automated…

In fact, RAT checks license header and tacks missing license. RAT provides a maven plug-in which can automate the missing license discovery during your build project. To use this plug-in, just add the following plug-in configuration in the build section of your pom file.

<plugin>
<groupid>org.codehaus.mojo</groupid>
<artifactid>rat-maven-plugin</artifactid>
<configuration>                
    <excludesubprojects>false</excludesubprojects>         
    <useeclipsedefaultexcludes>true</useeclipsedefaultexcludes>    
    <usemavendefaultexcludes>true</usemavendefaultexcludes>
    <excludes>
        <param>doc/**/*</param>
        <param>maven-eclipse.xml</param>
        <param>.checkstyle</param>
        <param>.externalToolBuilders/*</param>
        <param>LICENSE.*</param> 
        <param>.fbprefs</param>
    </excludes>
</configuration>
</plugin>

This configuration will check that non-excluded files have a correct license header. It excludes maven files (target folder), eclipse files (.project, .classpath). Those files don’t require a license, as they should not be on the source code repository. Then, others files can be excluded such as the doc folder (containing html files and release notes, used license files (LICENSE. *)... Extend the list (or modify it) according to your project.

To check that you have no file without a license header, just execute the following command:

mvn rat:check

The command failed if a corrupted file is detected. Executed on a multi-module project (each module need to be configured), it checks every module and failed as soon as a module has an invalid file.

So, by using these plug-ins, you can continuously check the consistency of your code format and of the license headers. This is not wonderful, but at least do one’s share of the work.