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/

Q outside the computer, wires organization

I feel proud of these two wire-organizers I have assembled, one of them is "original" (as far as I have never seen it anywhere), and other taken from a web (I do not remember what).

I was fed up of having an entire drawer only for wires and chargers, of bending themselves before every use, and I finally gave up of doing so. This way I designed these two solutions:

For USB wires, I hanged them using some papers-pin that, in turn, is grabbing a piece of cardboard stuck to a cupboard. It is easy to distinguish  which of the wires you need and easy to relocate once it is not necessary. Furthermore, it is nearby the computer, their maximum consumer.

For the mobile and other device chargers, the system was improved. As they cannot be seized by a paper-pin, I stuck a magnet to the chargers' head, and glued another magnets, correctly oriented, to another cardboard stuck to the cupboard.

I really love this system because it is really fast, tidy, easy to maintain and ... smart! And black over black does not attract attention.

Conclusion: This works because this is already being used. That's the key of success of a methodology or system.

Managing Maven dependencies with an external dependencies repository

Content:

Maven abstract.

Tunning your Maven proyect

Maven standard folders

Managing dependencies with Maven

Adding a nature in Eclipse

Maven profiles inheritance

Managing Maven dependencies with an external dependencies repository

I have been talking a lot about Maven dependencies for a local machine. It is high time to start talking about remote dependencies.

When you define a dependency in your pom.xml file, that dependency is sought in repo1.maven.org. But your libraries and internal dependencies are not there. Certainly they are in your local repository, but not in your workmate's own.

I do not find necessary to speak in favour of a code repository, the reasons are widely known. Reasons for a dependency repository might be less known because code is always used, but Maven is not (always).
Basic scenario is easy to find nevertheless:

• You create a library for a project with Maven.
• You design that library as a dependency for that project.
• You might want your workmate to compile the project in his/her computer, but...
• Binaries should never be uploaded to code repository!
• Shared folders are system dependant and difficult to automatize, trace and export.
• We are looking for zero specific configuration in a compilation.

If you could only upload to a private repo1.maven.org repository in order to make accessible an internal dependency for your company... You can!

There are two main open-source implementation for this task: Nexus and Artifactory. Both seem alike, but I chose to know deeply the last one, maybe I could find some time for comparing both in installation, configuration and performance. 

If you had in your pom.xml a configuration like this:

    <repositories>

        <repository>

            <snapshots />

            <id>snapshots</id>

            <name>libs-internal</name>

            <url>http://localhost:8080/artifactory/libs-internal</url>

        </repository>

    </repositories>

With this entry in pom.xml, we are asking Maven to search in this URL for any dependency we might need, and, for being in pom.xml, that configuration is project-scoped, being shared with the project itself in code repository.

All we have to keep in mind is that the server MUST be accessible by any of your partners who you are expecting to compile the project. In this example, our partners will find that they do not have Artifactory installed in their localhost, and you will find lots of complains for creating a local-dependant configuration for a department project.

Your second try made it better:

        <repository>

            <snapshots />

            <id>snapshots</id>

            <name>libs-internal</name>

            <url>http://srvmachine:8080/artifactory/libs-internal</url>

        </repository>

and now, if that machine is accessible for all your department, and permissions are well configured, so firewall is, and half a dozen more configurations, your dependencies would be able to download broadly.

However, as you find comfortable to download dependencies, you will find awful to upload your libraries manually through web interface. It is possible as well to improve this.

With the correct Artifactory and Nexus (trying to be neutral by now) settings, you can automatize your system for uploading a library once it is compiled by Maven:

<distributionManagement>
    <repository>
        <id>linux-wdx0</id>
        <name>linux-wdx0-releases</name>
        <url>http://srvmachine:8080/artifactory/libs-release-local</url>
    </repository>
</distributionManagement>


by typing "mvn deploy" instead of "mvn install" in your Maven console or IDE compilation button.

Now you can enjoy of an easy way to share and download department-scoped libraries within your department in a new fashion way of making things work. Your objetive: your project should compile and run only by downloading it in any machine with zero configuration.

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.