Maven Plugins - Extending the Maven Java Build Tool

Evgeny Goldin, http://evgenyg.io/

Maven Plugins is a collection of tools providing additional behavior to the traditional set of the open source Maven Java build tool capabilities. It allows a Maven developer to conveniently perform various tasks, such as:

• Copy, pack, unpack, download, or upload files, archives and Maven dependencies.
• Generate Hudson jobs using hierarchical definition of tasks.
• Create new Maven properties dynamically with Groovy.
• Send mails with attachments, run SSH commands remotely or invoke SpringBatch jobs.

Web Site: https://github.com/evgeny-goldin/maven-plugins
Version Tested: 0.2, 0.2.1 on Window 7 / Server 2008, Java 1.6.0_20, Maven 2.2.1 and 3.0.2
License & Pricing: Open Source (Apache license), Free
Support: https://github.com/evgeny-goldin/maven-plugins/issues

Since Maven is a Java tool and all of the plugins are developed in Groovy, a JVM-based language, they will work on any platform where Java 1.6 is supported.

Installation

In Maven plugins are referenced in a "pom.xml" file by their <groupId> and <artifactId> in order to be used.

<plugin>
<groupId>com.goldin.plugins</groupId>
<artifactId>maven-copy-plugin</artifactId>
<version>0.2.1</version>
<executions>
...
</executions>
</plugin>

For any plugin listed below you should replace the <artifactId> section by the corresponding plugin name, marked in bold in the example above.

A public Maven repository available at http://evgeny-goldin.org/artifactory/plugins-releases/ contains all plugin files so it should be added as a <pluginRepository> to your "pom.xml" file. Detailed instructions are available in Maven POM reference at http://maven.apache.org/pom.html#Repositories.

In addition, the http://evgeny-goldin.org/artifactory/libs-releases/ repository should also be added as <repository> to your "pom.xml" file to retrieve additional dependencies.

Alternatively, you can add both repositories to your Maven repository manager, such as Artifactory (http://www.jfrog.com/) or Nexus (http://nexus.sonatype.org/).

Usage

Each plugin provides a different set of functionalities. The section below briefly describes each of them.

maven-copy-plugin - http://evgeny-goldin.com/wiki/Maven-copy-plugin

Historically, Maven is targeted at the creation of standard archives supported by Java tools, such as "*.jar", "*.war" or "*.ear". These days many projects drift away from Java EE standards and use proprietary distribution archives with a less traditional structure to fit their needs. This plugin provides a set of capabilities required for convenient and centralized handling of archive preparation and distribution:

• Copying files with their content filtered or replaced based on Regex matches.
• Packing and unpacking of archives and Maven dependencies.
• Updating existing archives or unpacking specific Zip entries instead of unpacking the whole archive.
• Attaching archives created as Maven artifacts or deploying them to a Maven repository.
• Downloading and uploading archives from and to HTTP, FTP and SCP locations.
• Selecting the files copied, packed, unpacked, downloaded or uploaded with include/exclude patterns and dynamic Groovy expressions.
• Post processing of the files copied, packed, unpacked or downloaded using dynamic Groovy expressions.

maven-hudson-plugin - http://evgeny-goldin.com/wiki/Maven-hudson-plugin

Hudson is a Continuous Integration build server. It allows executing and monitoring jobs of any kind, with a preference towards build jobs. You can read more about it at http://hudson-ci.org/.

The Hudson execution unit is a "job", and each on is responsible for a single process, such as running a build tool like Maven or a batch processing engine like SpringBatch (http://static.springsource.org/spring-batch/). Consequently, each Hudson server contains more than one job as all of them are separated into groups of activities: nightly build jobs, continuous integration regular build jobs, monthly release jobs, periodic batch processing jobs or jobs that are invoked on demand and parameterized by a human before they start.

Normally Hudson jobs are defined, configured and updated manually, which becomes an issue as the number of jobs grows. A company with 30 or more Hudson jobs is not uncommon, yet Hudson administrators configure most of the jobs on a one-by-one basis, a process that is both error-prone and tedious. It becomes even more problematic when a number of jobs share certain behavior and properties, such as Maven goals or SVN repository addresses. A "template" job can be used but it only helps once and doesn’t provide support for cases when jobs need to be modified with an updated property after they are created.

This plugin allows for creating any amount of Hudson jobs from a single Maven POM, thus making all job definitions and configurations centralized. Jobs can form hierarchical groups allowing jobs at the top of the hierarchy to provide a set of common properties which are inherited and reused by the jobs at lower levels of hierarchy. Every time the plugin is executed, a single "config.xml" file per job is generated in the Hudson configuration directory where all job definitions are kept. Each file contains the job’s definition, settings, parameters and run-time instructions. Following this generation phase, the Hudson server needs to be restarted for new job definitions to be applied.

In addition to providing support for all standard job properties, such as memory settings, code repository URLs and Maven goals, this plugin provides a special support for jobs invocation and Artifactory repository integration. Jobs invocation allows one job to invoke any number of other jobs upon completion or termination, and Artifactory support allows a job to deploy artifacts created to an Artifactory repository manager (http://www.jfrog.com/) upon successful completion. Unlike the traditional Maven approach where artifacts are deployed as a build process progresses, deploying to Artifactory only happens after a successful job completion thus ensuring that within a single deploy phase no partial artifacts deployment resulting from a faulty job will ever occur.

maven-assert-plugin - http://evgeny-goldin.com/wiki/Maven-assert-plugin

Batch processes and build jobs usually have a goal of producing an outcome such as updating data storages, creating distribution archives or sending out mails with up-to-date statistics or reports. Less consideration is usually given to the process and, consequently, the running code tends to spend fewer efforts on verifying that run-time and environmental conditions match original assumptions. People may take for granted that, for example, all files required contain correct data and that essential resources, such as HTTP servers or RDBMS databases, are available. Failing to verify those assumptions may cause the build job or batch process to fail but, as it happens, this is the best and expected scenario.

Unfortunately, it may also happen that build job or batch process continues to execute but it operates in a diverged or awry environment, silently producing incorrect results without anybody noticing them. This behavior may cause undesirable errors to spread and cause damages such as data corruptions or wrong decisions being made in downstream activities.

This problem has been known to software development industry for years and the generally used solution is called assertions or verifications. While machine code is executed toward its goal, it also verifies that surrounding environments, files, variables or other resources contain legal and expected values in a specific range.

This plugin allows a Maven job to reuse this solution and apply it to build and batch processing. It makes assertions part of the build job, on par with other build instructions and targets.

The following assertions are supported:

• Verifying that certain Maven properties are defined. This becomes useful when some of them are expected to be passed on the command line or by a Hudson job as parameters.
• Verifying that certain directories or files of specific type exist. It is useful to verify the existence of data files that should be read, written or otherwise treated by the build or batch process.
• Verifying that certain directories contain identical files. It is useful for integration testing processes where this assertion may validate that results generated are identical to expected ones created in advance.
• Verifying that a given Groovy expression evaluates to true. When the assertions described above don’t provide the functionality required, it is possible to provide a Groovy expression that will dynamically check any assumption required, thus making verification very dynamic in nature.

maven-mail-plugin - http://evgeny-goldin.com/wiki/Maven-mail-plugin

Sending emails is a traditional phase of any build or batch process. Yet, Maven provides very little support to do so as part of the build process. This duty is usually taken on by bigger tools such as build servers, repository managers and code analysis tools.

This plugin allows the build to send email with attachments specified as part of the build process. Any number of "To", "Cc" or "Bcc" recipients may be specified, as well as files to attach. Message subject and body are configurable as well.

maven-properties-plugin - http://evgeny-goldin.com/wiki/Maven-properties-plugin

Build and batch processes tend to be very static. It doesn’t happen a lot that they behave differently each time they are executed. "Reproducibility" is one of possible requirements to a build process, with the expectation that under identical conditions the same build job will produce an identical result.

Having this background and reproducibility requirement, it becomes hard or impossible to introduce variations in how specific build jobs or batch processes execute. Parameterizing part of them with dynamically calculated values or running them conditionally, when specific criteria is met, is something that may well be required but is not favored by existing tools.

This plugin allows for introducing dynamic behavior into rigid and static Maven processes by giving the developer a way to create new variables at any time using Groovy expressions. In addition, any of the plugins mentioned above support conditional execution where such variables can also be used. A combination of variable creation and conditional execution allows for modifying run-time characteristics and flow of build jobs or batch processes according to any requirement or business need.

As a result, process "reproducibility" can be lost but many times nobody expects that a batch, or any other dynamic process, will always behave the same. At times, an immediate outcome from a specific process, such as an email sent or data storage updated, is of higher importance than an ability to repeat it in the future with an identical result.

Summary

Maven plugins provide a standard basis for any Maven build job or batch processing activity. This set of tools provides additional elements to enhance those traditionally available in the Maven ecosystem. By using them, developers gain a significant productivity increase and less code or configurations to maintain. Eventually, this results in a product of a higher quality and lower maintenance cost, something that is always valued highly.

---

Related Resources

• Java Videos and Tutorials

---

Click here to view the complete list of tools reviews

This article was originally published in the Spring 2011 issue of Methods & Tools