It's time to introduce one of the most important Maven concepts: how plugin goals are tied to lifecycle phases. This happens through packaging types. The packaging type is specified in the pom.xml
descriptor through the <packaging>
element, usually after its Maven coordinates. The default packaging type is jar
. The plugin goals that are executed by default in each phase of the lifecycle depend on the packaging type of the project that we will build. This is because we need to execute different tasks for different packaging types. Let's see some details about the most common packaging types and their default bindings.
This is the default packaging type. It produces an archive in the JAR format. Its default bindings in the default lifecycle are shown in the following table. The plugin goal is expressed in the <plugin-prefix>:<goal-name>
form.
Lifecycle phase |
Plugin goal |
---|---|
process-resources |
|
compile |
|
process-test-resources |
|
test-compile |
|
test |
|
package |
|
install |
|
deploy |
|
We can see that the plugin goals are the same as those we encountered when we built our sample module, transportation-acq-ejb
.
The WAR packaging type binds the war
goal of maven-war-plugin
to the package phase. This goal creates a web application archive using the JSP pages and XML descriptors under /src/main/webapp
, the compiled classes of the project, and all the JAR dependencies that have the compile
or runtime
scope. We'll speak later about dependencies and dependency scopes. The default bindings of the WAR packaging type are shown in the following table:
Lifecycle phase |
Plugin goal |
---|---|
process-resources |
|
compile |
|
process-test-resources |
|
test-compile |
|
test |
|
package |
|
install |
|
deploy |
|
This is the packaging type of project parent POM files (such as the transportation-project
parent POM of our sample) or aggregate POM files (that we'll discuss later in this chapter). Here, there aren't source files to process or compile; we only need to install and deploy the POM, along with its site descriptor, if present. Here are the default bindings of the POM packaging type:
Lifecycle phase |
Plugin goal |
---|---|
package |
|
install |
|
deploy |
|
This packaging type differs from the JAR packaging type in the package
phase, in which the ejb:ejb
goal of maven-ejb-plugin
is used in place of the jar:jar
goal of maven-jar-plugin
. The ejb:ejb
goal behaves like the jar:jar
goal, but in addition, it checks for the presence of the ejb-jar.xml
descriptor when the ejbVersion
configuration parameter of the plugin is set to 2.x
(the default). If this descriptor is missing, an error is thrown. As the ejb-jar.xml
descriptor is not needed when we use EJB version 3.x, we should explicitly configure maven-ejb-plugin
, specifying EJB version 3.x. This way, we will obtain the exact same result as when using the jar:jar
plugin goal, and ultimately, the JAR packaging type. For this reason, we used the JAR instead of the EJB packaging type in the EJB modules of our sample project. The following table shows the default bindings of the EJB packaging type:
Lifecycle phase |
Plugin goal |
---|---|
process-resources |
|
compile |
|
process-test-resources |
|
test-compile |
|
test |
|
package |
|
install |
|
deploy |
|
For more information on maven-ejb-plugin
, we can ask for help from Maven using the Maven Help Plugin:
$ mvn help:describe –Dplugin=ejb –Ddetail
The EAR packaging type binds maven-ear-plugin
to the generate-resources
and
package
phases of the default lifecycle. It generates the application.xml
descriptor and Java EE Enterprise Archive. Its default bindings are shown in the following table:
Lifecycle phase |
Plugin goal |
---|---|
generate-resources |
|
process-resources |
|
package |
|
install |
|
deploy |
|
We can find a complete reference for the built-in lifecycles on the Maven site, http://maven.apache.org, navigating to Documentation | Introduction | The Build Lifecycle. We can wonder where these lifecycles and default bindings are actually defined. All these definitions are in the Maven core library, maven-core-<Maven version>.jar
, under the /lib
subdirectory of the Maven installation. For example, in maven-core-3.2.1.jar
, under the META-INF/plexus
folder, we can find the components.xml
and default-bindings.xml
descriptors. These two descriptors contain the lifecycle definitions and their default bindings, respectively. Looking at the components.xml
descriptor, we can see the following elements:
<component> <role>org.apache.maven.lifecycle.Lifecycle</role> <implementation>org.apache.maven.lifecycle.Lifecycle</implementation> <role-hint>default</role-hint> <configuration> <id>default</id> <phases> <phase>validate</phase> <phase>initialize</phase> <phase>generate-sources</phase> <phase>process-sources</phase> <phase>generate-resources</phase> <phase>process-resources</phase> <phase>compile</phase> <phase>process-classes</phase> <phase>generate-test-sources</phase> <phase>process-test-sources</phase> <phase>generate-test-resources</phase> <phase>process-test-resources</phase> <phase>test-compile</phase> <phase>process-test-classes</phase> <phase>test</phase> <phase>prepare-package</phase> <phase>package</phase> <phase>pre-integration-test</phase> <phase>integration-test</phase> <phase>post-integration-test</phase> <phase>verify</phase> <phase>install</phase> <phase>deploy</phase> </phases> </configuration> </component>