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.
In this chapter, we will discuss the following topics:
assembly
pluginassembly
descriptorThe 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.
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.
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
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.
18.191.29.22