Other useful Maven plugins, Reporting and Site (Part III)

FindBugs Maven Plugin

FindBugs looks for bugs in Java programs. It is based on the concept of bug patterns. A bug pattern is a code idiom that is often an error. Bug patterns arise for a variety of reasons:
Difficult language features
Misunderstood API methods
Misunderstood invariants when code is modified during maintenance
Garden variety mistakes: typos, use of the wrong boolean operator

FindBugs uses static analysis to inspect Java bytecode for occurrences of bug patterns. We have found that FindBugs finds real errors in most Java software. Because its analysis is sometimes imprecise, FindBugs can report false warnings, which are warnings that do not indicate real errors. In practice, the rate of false warnings reported by FindBugs is generally less than 50%.

Usage:
[<reporting>]
<plugins>
    <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>findbugs-maven-plugin</artifactId>
        <version>2.3.1</version>
        <configuration>
            <excludeFilterFile>${findBugs.excludeFilterFile}</excludeFilterFile>
        </configuration>
    </plugin>
</plugins>
[</reporting>]

Notice that you can make ignore some classes in its analysis, by putting some value on excludeFilterFile property.

Source: http://mojo.codehaus.org/findbugs-maven-plugin/index.html


Maven CheckStyle Plugin

The Checkstyle Plugin generates a report regarding the code style used by the developers. For more information about Checkstyle, see http://checkstyle.sourceforge.net/. This version of the plugin uses Checkstyle 5.0.

The plugin can be configured in the project's POM. Predefined rulesets are included with the plugin, these are: sun_checks.xml, turbine_checks.xml, avalon_checks.xml and maven_checks.xml. You can also use a custom ruleset by specifying it in the plugin configuration.

Usage:
[<reporting>]
<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>

        <artifactId>maven-checkstyle-plugin</artifactId>

        <version>2.6</version>

        <configuration>

            <configLocation>PUT HERE YOUR CONFIGURATION</configLocation>

            <consoleOutput>true</consoleOutput>

        </configuration>

    </plugin>
</plugins>
[</reporting>]

Related: http://looking4q.blogspot.com/2011/01/checkstyle-configuration-distribution.html
Source: http://maven.apache.org/plugins/maven-checkstyle-plugin/index.html


Maven PMD Plugin

The PMD plugin allows you to automatically run the PMD code analysis tool on your project's source code and generate a site report with its results. It also supports the separate Copy/Paste Detector tool (or CPD) distributed with PMD.

The plugin accepts configuration parameters that can be used to customize the execution of the PMD tool.

Usage:
[<reporting>]
<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>

        <artifactId>maven-pmd-plugin</artifactId>

        <version>2.5</version>

        <configuration>

            <targetJdk>${java-version}</targetJdk>

            <excludes>

                <exclude>${pmd.excludes}</exclude>

            </excludes>

        </configuration>

    </plugin>
</plugins>
[</reporting>]

Notice you can make PMD plugin to ignore some classes.

Source: http://maven.apache.org/plugins/maven-pmd-plugin/

Maven Javadoc Plugin

The Javadoc Plugin uses the Javadoc tool to generate javadocs for the specified project. For more information about the standard Javadoc tool, please refer to Reference Guide.

Usage:
[<reporting>]
<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>

        <artifactId>maven-javadoc-plugin</artifactId>

        <version>2.7</version>

    </plugin>
</plugins>
[</reporting>]

Source: http://maven.apache.org/plugins/maven-javadoc-plugin/

JMR Maven Plugin

The JXR Plugin produces a cross-reference of the project's sources. The generated reports make it easier for the user to reference or find specific lines of code. It is also handy when used with the PMD Plugin for referencing errors found in the code.

Usage:
[<reporting>]
<plugins>
    <plugin>
        <groupId>org.codehaus.mojo</groupId>

        <artifactId>jxr-maven-plugin</artifactId>

        <version>2.0-beta-1</version>

    </plugin>
</plugins>
[</reporting>]

Source: http://maven.apache.org/plugins/maven-jxr-plugin/

Taglist Maven Plugin

The Taglist Maven Plugin generates a report on various tags found in the code, like @todo or //TODO tags.

Usage:
[<reporting>]
<plugins>
    <plugin>
        <groupId>org.codehaus.mojo</groupId>

        <artifactId>taglist-maven-plugin</artifactId>

        <version>2.4</version>

    </plugin>
</plugins>
[</reporting>]

Source: http://mojo.codehaus.org/taglist-maven-plugin/

Maven Site Plugin

All the previous plugins are meant to provide data to three possible targets. Humans, Hudson/Jenkins or Maven Site

The Site Plugin is used to generate a site for the project. The generated site also includes the project's reports that were configured in the <reporting> section of the POM.

Once you execute "mvn site", a html site is created in your target/site directory, where all or most of previous reports are presented, together with project information like developers, scm or issues.

Usage:
[<reporting>]
<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>

        <artifactId>maven-site-plugin</artifactId>

        <version>2.0-beta-6</version>

        <configuration>

            <locales>en</locales>

            <outputEncoding>${project.reporting.outputEncoding}</outputEncoding>

        </configuration>

    </plugin>
</plugins>
[</reporting>]

Source: http://maven.apache.org/plugins/maven-site-plugin/

Other useful Maven plugins (Part II)

BuildNumber Maven Plugin

This mojo is designed to get a unique build number for each time you build your project. So while your version may remain constant at 1.0-SNAPSHOT for many iterations until release, you will have a build number that can uniquely identify each build during that time. The build number is obtained from scm, and in particular, at this time, from svn. You can then place that build number in metadata, which can be accessed from your app, if desired.

The mojo also has a couple of extra functions to ensure you get the proper build number. First, your local repository is checked to make sure it is up to date. Second, your local repository is automatically updated, so that you get the latest build number. Both these functions can be suppressed, if desired.

Optionally, you can configure this mojo to produce a revision based on a timestamp, or on a sequence, without requiring any interaction with an SCM system. Note that currently, the only supported SCM is subversion.

[<plugins>]
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>buildnumber-maven-plugin</artifactId>
    <version>1.0-beta-4</version>
    <executions>
        <execution>
            <phase>validate</phase>
            <goals>
                <goal>create</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <useLastCommittedRevision>true</useLastCommittedRevision>
        <doCheck>false</doCheck>
        <doUpdate>false</doUpdate>
        <providerImplementations>
            <svn>javasvn</svn>
        </providerImplementations>
    </configuration>
</plugin>
[</plugins>]


I use this plugin for a highly detailed file name and, in a interface variable, showing to user the build number of this compilation, in order to trace back any problem.


<build>
    <finalName>${project.artifactId}-${project.version} r${hudson-env}</finalName>
</build>




Maven Release Plugin


This plugin is used to release a project with Maven, saving a lot of repetitive, manual work. Releasing a project is made in two steps: prepare and perform.

I usually use this plugin manually for creating Tags, Branches and commit releases from command line. As far I have investigated, tagBase is project dependent, so they are scm parameters.

[<plugins>]
 <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-release-plugin</artifactId>
     <version>2.1</version>
     <configuration>
         <providerImplementations>
             <svn>javasvn</svn>
         </providerImplementations>
         <tagBase>http://desenvolupament/svn/projectes/root/tags</tagBase>
     </configuration>
     <dependencies>
         <dependency>
             <groupId>com.google.code.maven-scm-provider-svnjava</groupId>
             <artifactId>maven-scm-provider-svnjava</artifactId>
             <version>1.10</version>
         </dependency>
     </dependencies>
</plugin>
[</plugins>]


<scm>
<developerConnection>scm:svn:http://desenvolupament/svn/projectes/projects/scpr/trunk</developerConnection>
<connection>scm:svn:http://desenvolupament/svn/projectes/projects/scpr/trunk</connection>
<url>http://desenvolupament/svn/projectes/projects/scpr/trunk</url>
</scm>

Other useful Maven plugins (Part I)

Maven Compiler plugin 

The Compiler Plugin is used to compile the sources of your project. The default compiler is javac and is used to compile Java sources. Also note that at present the default source setting is 1.5 and the default target setting is 1.5, independently of the JDK you run Maven with.

Usage:
[<plugins>]
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
        <compilerVersion>${java-version}</compilerVersion>
        <source>${java-version}</source>
        <target>${java-version}</target>
        <encoding>${project.build.sourceEncoding}</encoding>
    </configuration>
</plugin>
[</plugins>]


Maven compiler settings:

compilerVersion: Version of the compiler to use, ex. "1.3", "1.5", if fork is set to true.
encoding: The -encoding argument for the Java compiler.
source: The -source argument for the Java compiler.
target: The -target argument for the Java compiler.

If source and target are equals, no room for error in what version should the compiler user to interpret your sources (source) and to create the binary (target). More information about -source and -target configuration over here.

More options about this plugin is over here.


Maven Resources plugin

The Resources Plugin handles the copying of project resources to the output directory. There are two different kinds of resources: main resources and test resources. The difference is that the main resources are the resources associated to the main source code while the test resources are associated to the test source code.

Thus, this allows the separation of resources for the main source code and its unit tests.

Starting with version 2.3 this plugin uses the Maven Filtering shared component for filtering resources.

[<plugins>]
<plugin>
    <artifactId>maven-resources-plugin</artifactId>
    <version>2.2</version>
    <configuration>
        <encoding>${project.build.sourceEncoding}</encoding>
     </configuration>
</plugin>
[</plugins>]

encoding: The character encoding scheme to be applied when filtering resources.


Maven Source plugin

The Source Plugin creates a jar archive of the source files of the current project. The jar file is, by default, created in the project's target directory.

They will be uploaded to your maven dependencies repository in deploy phase, and will be downloaded if necessary afterward.

[<plugins>]
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-source-plugin</artifactId>
    <version>2.1.2</version>
    <executions>
        <execution>
            <goals>
                <goal>jar</goal>
            </goals>
         </execution>
    </executions>
</plugin>
[<plugins>]



Maven  Eclipse plugin

The Eclipse Plugin is used to generate Eclipse IDE files (*.classpath, *.wtpmodules and the .settings folder) for use with a project.

[<plugins>]
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-eclipse-plugin</artifactId>
    <version>2.8</version>
    <configuration>
        <downloadSources>true</downloadSources>
        <downloadJavadocs>true</downloadJavadocs>
    </configuration>
</plugin>
[<plugins>]

Maven Eclipse settings:

downloadJavadocs: Enables/disables the downloading of javadoc attachments. Defaults to false. When this flag is true remote repositories are checked for javadocs: in order to avoid repeated check for unavailable javadoc archives, a status cache is mantained. With versions 2.6+ of the plugin to reset this cache run mvn eclipse:remove-cache, or use the forceRecheck option with versions. With older versions delete the file mvn-eclipse-cache.properties in the target directory.

downloadSources: Enables/disables the downloading of source attachments. Defaults to false. When this flag is true remote repositories are checked for sources: in order to avoid repeated check for unavailable source archives, a status cache is mantained. With versions 2.6+ of the plugin to reset this cache run mvn eclipse:remove-cache, or use the forceRecheck option with versions. With older versions delete the file mvn-eclipse-cache.properties in the target directory.


These sources were uploaded by Maven Source Plugin ;)



There will be more soon, then we could talk about how to organize them all.

CheckStyle Eclipse plugin. Installation

Content:

CheckStyle Eclipse plugin. Installation

Tunning your CheckStyle and Formatter

Every programmer working as only one

What if... I get a "Fileset from project [projectname] has no valid check configuration" Error?

CheckStyle configuration distribution

In the lollipop world, your code and my code are completely equal, it is also well formatted, well documented and optimized for every executer machine. In that world, bugs does not exist, clients only do what they are supposed to do and the big boss never downplays your suggestions.

In a perfect world, your code and mine differs but not so much, your cat never walk over your keyboard and your pretty workmate is in love for you.

In this very real world, the stupid mate will not format a line correctly unless Damocles insert his sword in his back-door, clients bring up over your user manual and, probably, over the inexistent specification. Ups, I almost forget it, your ugly workmate is sexually harassing you.


In order to pacify this war field, the first tool I bring to you is CheckStyle Eclipse Plugin.


Description from its webpage: Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. It automates the process of checking Java code to spare humans of this boring (but important) task. This makes it ideal for projects that want to enforce a coding standard.

The installation is quite easy, as said here, in your Eclipse/SpringSource just

1. In Eclipse go to Help->Software Updates...

2. Add a new installation site and providehttp://eclipse-cs.sf.net/update/ as location URL.

3. Mark the plugin version you would like to install, as well as future optional features, then press Install...

4. Review and confirm the plugins to install

5. Restart Eclipse



Afterwards, right click over your project -> CheckStyle -> Activate CheckStyle. Then you might find something like this:




You are able to see my best code ;) (I am sorry for Spanish description).

A bit summary of warnings in the code window:

-Javadoc is missing
-Missing package-info java file
-Comment is like to-do comment
- { should be in previous line
...
among others.


Firstly, with a Source -> Format (Ctrl + Shift + F) we will keep aesthetic warnings low.

I pass from 34 to 26 warnings, check how "{" have been moved and now they pass CheckStyle filter.

The Formatter and the Checkstyle Plugin must be synchronized, otherwise every formatting you do, and you should delegate format in tools like this, you will gain CheckStyle warnings in an endless war.

Benefits for a single programmers are limited, but benefits for a entire team that must work together are incalculable. If not this, tools like CheckStyle (and an automatic code formatter) are obligatory in every development department.


An article about Tunning CheckStyle in the oven...