The psalm of sojourns : MAVEN: An intro to the master of project build

What is Maven?

Maven is a build tool for Java software projects. You can build projects using other languages too, but Maven is used more for Java projects, as it is developed in Java.

As per the Philosophy of Maven, and it's official site it is more than just a build tool.

What is a Build tool?

A build tool is a tool that automates everything related to building the software project. Building a software project typically includes one or more of these activities:

Generating source code (if auto-generated code is used in the project).

Generating documentation from the source code.

Compiling source code.

Packaging compiled code into JAR files or ZIP files.

Installing the packaged code on a server, in a repository or somewhere else.

Maven Build Life Cycles, Phases and Goals

When Maven builds a software project it follows a build life cycle. The build life cycle is divided into build phases, and the build phases are divided into build goals.

Build Life Cycles

Maven has 3 built-in build life cycles. These are:

default
clean
site

Each of these build life cycles are executed independently of each other. You can get Maven to execute more than one build life cycle, but they will be executed in sequence, separately from each other.

The default life cycle handles everything related to compiling and packaging your project.

The clean life cycle handles everything related to removing temporary files from the output directory, including generated source files, compiled classes, previous JAR files etc.

The site life cycle handles everything related to generating documentation for your project. In fact, site can generate a complete website with documentation for your project.

Build Phases

Each build life cycle is divided into a sequence of build phases, and the build phases are again subdivided into goals. Thus, the total build process is a sequence of build life cycle(s), build phases and goals.

You can execute either a whole build life cycle like clean or site, a build phase like install which is part of the default build life cycle, or a build goal like dependency:copy-dependencies. Note: You cannot execute the default life cycle directly. You have to specify a build phase or goal inside the default life cycle.

When you execute a build phase, all build phases before that build phase in this standard phase sequence are executed. Thus, executing the install build phase really means executing all build phases before the install phase, and then executes the install phase after that.

Build Goals

Build goals are the finest steps in the Maven build process. A goal can be bound to one or more build phases or to none at all. If a goal is not bound to any build phase, you can only execute it by passing the goals name to the mvn command. If a goal is bound to multiple build phases, that goal will get executed during each of the build phases it is bound to.

The following lists all build phases of the default, clean and site lifecycles, which are executed in the order given up to the point of the one specified.

Clean Lifecycle

pre-clean	execute processes needed prior to the actual project cleaning
clean	remove all files generated by the previous build
post-clean	execute processes needed to finalize the project cleaning

Default Lifecycle

validate	validate the project is correct and all necessary information is available.
initialize	initialize build state, e.g. set properties or create directories.
generate-sources	generate any source code for inclusion in compilation.
process-sources	process the source code, for example to filter any values.
generate-resources	generate resources for inclusion in the package.
process-resources	copy and process the resources into the destination directory, ready for packaging.
compile	compile the source code of the project.
process-classes	post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.
generate-test-sources	generate any test source code for inclusion in compilation.
process-test-sources	process the test source code, for example to filter any values.
generate-test-resources	create resources for testing.
process-test-resources	copy and process the resources into the test destination directory.
test-compile	compile the test source code into the test destination directory
process-test-classes	post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.
test	run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
prepare-package	perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)
package	take the compiled code and package it in its distributable format, such as a JAR.
pre-integration-test	perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test	process and deploy the package if necessary into an environment where integration tests can be run.
post-integration-test	perform actions required after integration tests have been executed. This may including cleaning up the environment.
verify	run any checks to verify the package is valid and meets quality criteria.
install	install the package into the local repository, for use as a dependency in other projects locally.
deploy	done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

Site Lifecycle

pre-site	execute processes needed prior to the actual project site generation
site	generate the project's site documentation
post-site	execute processes needed to finalize the site generation, and to prepare for site deployment
site-deploy	deploy the generated site documentation to the specified web server

The full Maven lifecycle is defined by the components.xml file in the maven-core module, with associated documentation for reference.

In Maven 2.x, default lifecycle bindings were included in components.xml, but in Maven 3.x, they are defined in a separate default-bindings.xml descriptor.

Core of Maven - the POM xml

The core of Maven is the concept of POM files (Project Object Model). It is an xml file located in root directory of the project, which is hierarchical representation of project resources like source code, test code, dependencies. The execution steps of Maven is as follows:

> Reads POM.xml

> Downloads dependencies into local repository

> Executes life cycles, build phases and/or goals

> Executes plugins

POM describes what to build. Maven build phases describes how to build.

Profiles

A new feature of the POM 4.0 is the ability of a project to change settings depending on the environment where it is being built. A profile element contains both an optional activation (a profile trigger) and the set of changes to be made to the POM if that profile has been activated. For example, a project built for a test environment may point to a different database than that of the final deployment. Or dependencies may be pulled from different repositories based upon the JDK version used.

http://maven.apache.org/pom.html#Profiles

Creating the POM File

Once you have created the project root directory, create a file called pom.xml inside the directory.

Inside the pom.xml file you put the following XML:

<project xmlns="http://maven.apache.org/POM/4.0.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

http://maven.apache.org/xsd/maven-4.0.0.xsd">

<modelVersion>4.0.0</modelVersion>

<groupId>blogger</groupId>

<artifactId>hello-world</artifactId>

<version>1.0.0</version>

</project>

This is a minimal pom.xml file.

The groupId identifies your organization.

The artifactId identifies the project. More specifically, it identifies the artifact built from the project, like for instance a JAR file.

The version identifies the version of the artifact which the POM file builds. When you evolve the project and you are ready to release, remember to update the version number.

Other projects that need to use your artifact will refer to it using the groupId, artifactId and version, so make sure to set these to some sensible values.

Testing the POM File

When you have created the pom.xml file inside the project root directory it is a good idea to just test that Maven works, and that Maven understands the pom.xml file.

To test the pom.xml file, navigate to the project root directory, then open command window there, then execute this command:

mvn clean

The mvn clean command will clean the project directory for any previous temporary build files. Since the project is all new, there will be no previous build files to delete. The command will thus succeed.

You will see that Maven writes what project it has found. It will output that to the command prompt. This is a sign that Maven understands your POM. Here is an example of what Maven could output:

D:\projects\my-first-maven-project>mvn clean

[INFO] Scanning for projects...

[INFO]