Chapter 6. Maven Assemblies

Maven provides an extensible architecture via plugins and lifecycles. Archive types such as .jar, .war, .ear, and many more are supported by plugins and associated lifecycles. The JAR plugin creates an artifact with the .jar extension and the relevant metadata, according to the JAR specification. The JAR file is, in fact, a ZIP file with the optional META-INF directory. You can find more details about the JAR specification from http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html.

The JAR file aggregates a set of class files to build a single distribution unit. The WAR file aggregates a set of JAR files, Java classes, JSPs, images, and many more resources into a single distribution unit that can be deployed in a Java EE application server. However, when you build a product, you might need to aggregate many JAR files from different places, WAR files, README files, LICENSE files, and many more into a single ZIP file. To build such an archive, we can use the Maven assembly plugin.

Maven Assemblies

In this chapter, we will discuss the following topics:

  • The Maven assembly plugin
  • The assembly descriptor
  • Artifact/resource filters
  • An end-to-end example to build a custom distribution archive

The Maven assembly plugin produces a custom archive, which adheres to a user-defined layout. This custom archive is also known as the Maven assembly. In other words, it's a distribution unit, which is built according to a custom layout.

The assembly plugin

Let's have a quick look at a real-world example, which uses the assembly plugin.

WSO2 Identity Server (WSO2 IS) is an open source identity and entitlement management product distributed under the Apache 2.0 license as a ZIP file. The ZIP distribution is assembled using the Maven assembly plugin. Let's have a look at the root POM file of the distribution module of WSO2 IS, which builds the Identity Server distribution, available at https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/products/is/5.0.0/modules/distribution/pom.xml.

First, pay attention to the plugins section of the POM file. Here, you can see that maven-assembly-plugin is associated with the project. Inside the plugin configuration, you can define any number of executions with the execution element, which is a child element of the executions element. The configuration is as follows:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-assembly-plugin</artifactId>
  <executions>
    <execution>
      <id>copy_components</id>
      <phase>test</phase>
      <goals>
        <goal>attached</goal>
      </goals>
      <configuration>
        <filters>
          <filter>${basedir}/src/assembly/filter.properties
          </filter>
        </filters>
        <descriptors>
          <descriptor>src/assembly/dist.xml</descriptor>
        </descriptors>
      </configuration>
    </execution>
    <execution>
      <id>dist</id>
      <phase>package</phase>
      <goals>
        <goal>attached</goal>
      </goals>
      <configuration>
        <filters>
          <filter>${basedir}/src/assembly/filter.properties
          </filter>
        </filters>
        <descriptors>
          <descriptor>src/assembly/bin.xml</descriptor>
          <descriptor>src/assembly/src.xml</descriptor>
          <descriptor>src/assembly/docs.xml</descriptor>
        </descriptors>
      </configuration>
    </execution>
  </executions>
</plugin>

If you look at the first execution element, it associates the attached goal of the assembly plugin with the test phase of the default lifecycle. In the same manner, the second execution element associates the attached goal with the package phase of the default lifecycle.

Note

The Maven default lifecycle includes: validate -> initialize -> generate-sources -> process-sources -> generate-resources -> process-resources -> compile -> process-classes -> generate-test-sources -> process-test-sources -> generate-test-resources -> process-test-resources -> test-compile -> process-test-classes -> test -> prepare-package -> package -> pre-integration-test -> integration-test -> post-integration-test -> verify -> install -> deploy.

Everything inside the configuration element is plugin specific. In this case, the Maven assembly plugin knows how to process the filters and descriptors elements.

In this particular example, only the attached goal of the assembly plugin is used. The assembly plugin introduces eight goals; however, six of them are deprecated, including the attached goal. It is not recommended that you use any of the deprecated goals. Later, we'll see how to use the single goal of the assembly plugin instead of the deprecated attached goal. The following lists out the six deprecated goals of the assembly plugin. If you are using any of them, you should migrate your project to use the single goal, except for the last one, the directory-unpack goal. For this, you need to use the unpack goal of the Maven dependency plugin.

  • assembly:assembly
  • assembly:attached
  • assembly:directory
  • assembly:unpack
  • assembly:directory-single
  • assembly:directory-inline

Note

More details about the Maven assembly plugin and its goals can be found at http://maven.apache.org/plugins/maven-assembly-plugin/plugin-info.html.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.191.29.22