Maven 2 lifecycle phases

In Maven 2, this notion is standardized into a set of well-known and well-defined lifecycle phases(see figure). Instead of invoking plug-ins, the Maven 2 developer invokes a lifecycle phase: $mvn compile. All the dependencies, goals, tasks, plugins which belong to this life cycle phase will be invoked otherwise not.

maven life cycle phases

maven life cycle phases

For example if Trinidad report plugin is required to be executed during test phase then it can be configured in below way

 <execution>
    <id>Trinidad-report</id>
    <phase>compile</phase>
    <goals>
        <goal>java</goal>
    </goals>
    <configuration>
        <mainClass>com.ptc.fusion.fitnesse.fixture.SetDatesAsSystemProperties</mainClass>
    </configuration>
</execution>

 

Some useful Maven 2 lifecycle phases are the following:

  • generate-sources: Generates any extra source code needed for the application, which is generally accomplished using the appropriate plug-ins
  • compile: Compiles the project source code
  • test-compile: Compiles the project unit tests
  • test: Runs the unit tests (typically using JUnit) in the src/test directory
  • package: Packages the compiled code in its distributable format (JAR, WAR, etc.)
  • integration-test: Processes and deploys the package if necessary into an environment where integration tests can be run
  • install: Installs the package into the local repository for use as a dependency in other projects on your local machine
  • deploy: Done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects

 

The lifecycle phase invokes the plug-ins it needs to do the job. Invoking a lifecycle phase automatically invokes any previous lifecycle phases as well. Since the lifecycle phases are limited in number, easy to understand, and well organized, becoming familiar with the lifecycle of a new Maven 2 project is easy.

 

All Maven Default Lifecycle Phases

  1. validate
  2. generate-sources
  3. process-sources
  4. generate-resources
  5. process-resources
  6. compile
  7. process-classes
  8. generate-test-sources
  9. process-test-sources
  10. generate-test-resources
  11. process-test-resources
  12. test-compile
  13. test
  14. prepare-package (maven 2.1+)
  15. package
  16. pre-integration-test
  17. integration-test
  18. post-integration-test
  19. verify
  20. install
  21. deploy

There are a couple key concepts to be aware of with maven lifecycles. First off, if we call a particular phase via a maven command, such as “mvn compile”, all phases up to and including that phase will be executed. So, in the case of “mvn compile”, we would actually go through the validate, generate-sources, process-sources, generate-resources, process-resources, and compile phases. The second main concept to be aware of in regards to lifecycles is that, based on the packaging of a project (jar, war, ear, etc), different maven goals will be bound to different phases of the maven lifecycle.

 

Create War using command prompt

WAR stands for Web application ARchive. A Web application is a group of HTML pages, JSP pages, servlets, resources and source file, which can be managed as a single unit. A Web archive (WAR) file is a packaged(zipped/compressed) Web application. WAR files can be used to import a Web application into a Web server.

Here’s how to compress a ‘myWebApp’ web application into a “Web Archive” file named myWebApp.war so that you can easily transport it to another server.
* Open a command prompt and cd to
<Tomcat_home>\webapps\myWebApp
* Use the java archive command ‘jar’ to bundle up your application
jar -cvf myWebApp.war *

or go to one level before your web application folder  the folder you want to package as Web Archieve
you file is somewhere like d:\webapps\myWebApp
d:>cd webapps
d:\webapps:>jar -cvf myWebApp.war myWebApp

In English, “compress everything in this directory into a file named myWebApp.war”
(c=create, v=verbose, f=file)

Now you can copy myWebApp.war to any the webapps directory on a new Tomcat Server. When you save the file to a new server BE SURE not to save it as a ZIP file, choose “all files”. If Tomcat is running on the new server the war file will be automatically installed as soon as you save it. If not, start up Tomcat on the new server to install the application after you have saved it. Do NOT attempt to unzip the war file or do any installation yourself. Tomcat will do everything for you!

When the server is restarted it will automatically uncompress the files and recreate a web application named ‘myWebApp’.

How to create and deploy the jar to local repository using maven

Maven: Making a War and Jar at the Same Time
Maven 2 nice automates building WAR files, but it places your compiled classes in WEB-INF/classes instead of making a new jar in /WEB-INF/lib.

If you want your stuff to be compiled as a .jar as well as a .war, you can do this by specifying the jar goal in the command line:

[shell>mvn clean jar install

Note this will make myproject.jar in target/, not in target/myproject/WEB-INF/lib, so you will need to use the Ant plugin to move this stuff around.

But this is not always an option: for deep, modular builds using the reactor, you may want to build your whole thing using one “mvn install”. To do this, do the following:
Specify “war” packaging at the top of your pom.xml.
Then add the following to your build section.

<build>
</plugins>
<!–This plugin will create the jar for the project –>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>make-a-jar</id>
<phase>compile</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<!–This plugin will deploy the war in local repository–>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>install-file</goal>
</goals>
<configuration>
<packaging>jar</packaging>
<artifactId>${project.artifactId}</artifactId>
<groupId>${project.groupId}</groupId>
<version>${project.version}</version>
<file>
${project.build.directory}/${project.artifactId}-${project.version}.jar
</file>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
<build>