maven Build Lifecycle
a Maven
build lifecycle consists of
A set of well-defined phases. Each
phase groups a set of goals defined by
Maven plugins and the
lifecycle defines the order of exec Ution.
a Maven plugin is a collection of goals where each goal are responsible for performing A specific action.
The following figure shows the relationship between Maven plugin goals and lifecycle phases:
Let's take the simplest Maven build command This every Java developer is familiar with:
$ mvn clean install
What would this do? As a developer, how many times has you executed the previous command? Ever thought of what happens inside? If not, it's time to explore it now.
Standard
lifecycles in MavenMaven comes
with three-lifecycles:default, clean, and site. Each lifecycle defines its own set of phases.
The Clean
lifecycleThe clean lifecycle defines three phases:
Pre-clean, clean, and Post-clean.
a phase in a lifecycle was just an ordered placeholder in the build execution path.
For example, the clean phase in the clean lifecycle cannot does anything on its own. In the Maven architecture, it has both key elements:nouns and verbs. Both nouns and verbs, which is related to a given project, is defined in the POM file. The name of the project, the name of the parent project, the dependencies, and the type of the packaging are nouns. Plugins bring verbs into the Maven build system, and they define what needs to is done during the build execution via its Goals. A plugin is a
Group of goals. Each goal of a plugin can is executed on its own or can being registered as part of a phase in a Maven build lifecycle. When your type MVN clean, it executes all the phases defined in the clean lifecycle up to and including the clean phase. Don ' t be confused; In this command, the lifecycle, it's the name of the phase. It ' s only a coincidence that
The name of the phase happens to is the name of the lifecycle. In Maven, you cannot simply execute a lifecycle by its name-it have to be the name of a phase. Maven would find the corresponding lifecycle and would execute it up to the given phase (including
that phase).
When your type mvn clean, it cleans out project's working directory (by default, it's the target directory ). This was done via the Maven clean plugin. To find more details on the Maven clean plugin, type the following command. It describes all the
Goals defined inside the clean plugin:
<pre name= "code" class= "java" >$ mvn help:describe-dplugin=cleanname:maven clean plugindescription:the Maven Clea N Plugin is a Plugin this removes filesgenerated at Build-time in a project ' s directory. Group Id:org.apache.maven.pluginsArtifact id:maven-clean-pluginversion:2.5goal prefix:cleanthis plugin has 2 goals.cl Ean:cleanDescription:Goal, which cleans the build. This attempts-to-clean Aproject's working directory of the files that were generated atbuild-time. By default, it discovers and deletes the directoriesconfigured in Project.build.directory,project.build.outputdirectory , project.build.testoutputdirectory,andproject.reporting.outputdirectory.files outside the default mayalso be Included in the deletion by configuring the Filesets Tag.clean:helpDescription:Display Help information on MAVEN-CLEAN-PL Ugin. CALLMVN clean:help-ddetail=true-dgoal=<goal-name> to display parameterdetails. For more information, run ' mvn help:describe [...]-ddetail '
Everything in Maven is a plugin. Even the command we executed previously to get goal details of the "clean plugin executes another plugin:the" Help plugin. The following command would describe the help plugin itself:
$ MVN Help:describe-dplugin=help
Describe is a goal defined inside the Help plugin.
The clean plugin has a goals defined in It:clean and help. As mentioned previously, each goal of a plugin can being executed on its own or can being registered as part of a phase in a Mav En build lifecycle. A clean goal of the plugin
Can is executed on its own with the following command:
$ mvn clean:clean
The following figure shows the relationship between the Maven clean plugin goals and the clean lifecycle PHAs ES:
the first clean word in the previous command is the prefix of the plugin, while the second one is the name of the goal. When your type mvn clean, it's the same clean goal that gets executed. However, this time it gets executed through the clean phase of the clean lifecycle, and it also executes all the PHAs Es in the corresponding lifecycle up to the clean phase-not just the clean phase. The clean goal of the clean Plugin is configured by default to get executed during the clean lifecycle. The plugin goal to lifecycle phase mapping can be provided through the application POM file. If Not, it'll is inherited from the Super POM file. The super POM file, which defines The clean plugin by default, adds the plugin to the clean phase of the clean lifecy Cle. you cannot define the same phase in and different lifecycles.
The following code snippet shows how the clean goal of the Maven clean plugin are associated with the Clea n phase of the clean lifecycle:
<pre name= "code" class= "java" ><plugin> <artifactId>maven-clean-plugin</artifactId> <version>2.5</version> <executions> <execution> <id> default-clean</id> <phase>clean</phase> <goals> <goal>clean</goal > </goals> </execution> </executions></plugin>
The Pre-clean and Post-clean phases of the The clean lifecycle does not has any plugin bindings. The objective of the pre-clean phase is to perform any operations prior to the cleaning task and the objective of the post -clean phase is to perform
Any operations after the cleaning task. If you need to associate any plugins with these-phases, you simply need-add them to the corresponding plugin config Uration.
The
default lifecycleThe default lifecycle in Maven
defines phases. When you run the command
mvn clean Install, it'll execute all the phases from the default lifecycle up to and including the install PHASE. To be precise, Maven would first execute all the phases in clean lifecycle up to and including the clean phase, and would th En execute the default lifecycle up to and including the install phase.
The phases in the default lifecycle does not has any associated plugin goals. The plugin bindings for each phase is defined by the corresponding packaging. If the type of packaging of your Maven project is JAR and then it'll define its own set of
Plugins for each phase. If The packaging type is WAR and then it'll has its own set of plugins. The following points summarize all the phases defined under the default lifecycle in their order of execution:
?
Validate: This phase validates the project POM file and makes sure all the necessary information related to carry out of the build is Available.
? Initialize:This phase initializes the build is setting up to the right directory structure and initializing properties.
?
generate-sources:This phase generates any required source code.
?
process-sources: This phase processes the generated source code.
For example, there can is a plugin running in this phase to filter the source code based on some defined criteria.
?
generate-resources: This phase generates any resources, need to being packaged with the final artifact.
?
process-resources: This phase processes the generated resources. It copies the resources to their destination directories and makes them ready for packaging.
? Compile:This phase compiles the source code.
?
process-classes:This phase can is used to carry off any bytecode enhancements after the compile phase.
?
generate-test-sources:This phase generates the required source code for tests.
?
process-test-sources:This phase processes the generated test source code. For example, there can is a plugin running in this phase to filter the source code based on some defined criteria.
? Generate-test-resources:This phase generates all the resources required to run tests.
?
process-test-resources: This phase processes the generated test resources. It
copies the resources to their destinationDirectories and makes them ready for testing.
?
Test-compile:This phase compiles the source code for tests.
?
process-test-classes: This phase can is used to carry off any bytecode enhancements after the test-compile phase.
?
Test:This phase executes tests using the appropriate unit test framework.
?
Prepare-package:This phase was useful in organizing, the artifacts to be packaged.
?
Package: This phase packs the artifacts to a distributable format, for example, JAR or WAR.
?
pre-integration-test:This phase performs the actions required (if any) before running integration tests. This is used to start any external application servers and deploy the artifacts into different test environments.
? Integration-test:This phase runs integration tests.
? Post-integration-test:This phase can is used to perform any cleanup tasks after running the integration tests.
?
Verify: This phase verifies the validity of the package. The criteria to check for the validity needs to being defined by the respective plugins.
?
Install: This phase installs the final artifact in the local repository.
?
Deploy: This phase deploys the final artifact to a remote repository.
The packaging
type of a given Maven project is defined under the <packaging> element in the Pom . xml file. If the element is omitted and then Maven assumes it as jar packaging
The following figure shows all the phases defined under the Maven default lifecycle and their order of execution:
More details about Maven lifecycles can is found at http://maven.apache.org/ref/3.2.3/mavencore/ Lifecycles.html.
Let ' s has a look at a concrete example. Run the following command against a Maven project has the jar packaging. If you don't have such a project can download a sample Maven project from https://svn.wso2.org/repos/
wso2/people/prabath/maven/chapter04/jose/.
$ mvn help:describe-dcmd=deploy
Here we is using the Maven help plugin to find more details about the Deploy phase corresponding to the jar packaging, an D It'll produce the following output:
It is a part of the lifecycle for the POM packaging ' jar '. This lifecycle
Includes the following phases:
* Validate:not defined
* Initialize:not defined
* Generate-sources:not defined
* Process-sources:not defined
* Generate-resources:not defined
* Process-resources:org.apache.maven.plugins:maven-resourcesplugin:2.6:resources
* Compile:org.apache.maven.plugins:maven-compilerplugin:2.5.1:compile
* Process-classes:not defined
* Generate-test-sources:not defined
* Process-test-sources:not defined
* Generate-test-resources:not defined
* Process-test-resources:org.apache.maven.plugins:mavenresources-plugin:2.6:testresources
* Test-compile:org.apache.maven.plugins:maven-compilerplugin:2.5.1:testcompile
* Process-test-classes:not defined
* Test:org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test
* Prepare-package:not defined
* Package:org.apache.maven.plugins:maven-jar-plugin:2.4:jar
* Pre-integration-test:not defined
* Integration-test:not defined
* Post-integration-test:not defined
* Verify:not defined
* Install:org.apache.maven.plugins:maven-installplugin:2.4:install
* Deploy:org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
Now if you are in the package phase, you'll notice that we have a different plugin goal:maven-war-plugin.
Similarly to the jar and war packaging, each of the other packaging type defines their own bindings for the default LIFECYCL E.
Reading notes: Mastering Apache Maven 3
Copyright? Packt Publishing
MAVEN Build Lifecycle
