MAVEN

By

Mr. Ashok
Introduction
Maven was originally started as an attempt to simplify the build processes in the Jakarta Turbine project. There
were several projects each with their own Ant build files that were all slightly different and JARs were checked
into CVS. Apache wanted a standard way to build the projects, a clear definition of what the project consisted
of, an easy way to publish project information and a way to share JARs across several projects.
What resulted is a tool that can now be used for building and managing any Java-based project. We hope that
Apache created something that will make the day-to-day work of Java developers easier and generally help
with the comprehension of any Java-based project.

Maven's Objectives
Maven's primary goal is to allow a developer to comprehend the complete state of a development effort in
the shortest period of time. In order to attain this goal there are several areas of concern that Maven attempts
to deal with:

 Making the build process easy

 Providing a uniform build system
 Providing quality project information
 Providing guidelines for best practices development
 Allowing transparent migration to new features

What is Maven?
The answer to this question depends on your own perspective. The great majority of Maven users are going
to call Maven a “Build tool”: a tool used to build deployable artifacts from source code. Build engineers and
project managers calls Maven as something more comprehensive: A project management tool.
What is the difference between Build tool and Project Management tool?
A build tool (such as Ant) is focused solely on preprocessing, compilation, packaging, testing, and distribution.
A project management tool such as Maven provides a superset of features found in a build tool.
In addition to providing build capabilities, Maven can also run reports, generate a web site, and facilitate
communication among members of a working team.
Maven does following aspects of the project lifecycle automatically:
1) Downloads required jars
2) Compiles source code
3) Packaging project as .jar, .war, .ear, .pom, etc
4) Deploy project into Web server or Application server
5) Starts Server
6) Performs Unit testing
7) Un-deploy application from server
8) Stop Server
9) Prepares Test Report including Code coverage report
10) Builds Technical Site
Maven is an invaluable tool for Java development. Indeed, maven touches so many phases of the
SDLC lifecycle.
Is Maven alternative to XYZ tool?
So, sure, Maven is an alternative to Ant, but Apache Ant continues to be a great, widely-used tool. It has been
the reigning champion of Java builds for years, and you can integrate Ant build scripts with your project’s
Maven build very easily. This is a common usage pattern for a Maven project. On the other hand, as more and
more open source projects move to Maven as a project management platform, working developers are
starting to realize that Maven not only simplifies the task of build management, it is helping to encourage a
common interface between developers and software projects. Maven is more of a platform than a tool, while
you could consider Maven an alternative to Ant, you are comparing apples to oranges. "Maven" includes more
than just a build tool.

INSTALLATION
Maven is a pure java, so first of all we need to ensure JDK1.5 or above is installed and JAVA_HOME is set.
To download Maven, go to http://maven.apache.org/download.html and select the appropriate binary
archive format for your platform. The contents of the zip or tar.gz are the same.

To set up Maven, you need to:

 Download Maven and unzip it

 Create a JAVA_HOME System Variable
 Create an M2_HOME System Variable
 Add %JAVA_HOME%\bin;%M2_HOME%\bin; to your System Path

Go to My Computer -> Right click on My Computer -> Properties -> Advance System
Settings

Now, the installation process of Maven is completed. To check whether the installation process is
successful or not, go to Command Prompt and enter mvn -version. If the installation is successful,
the following output appears. Otherwise, an error will be shown
Maven Life Cycle
The main concept of Maven is the build life cycle, which has a sequence of phases that define the
order in which the goals have

The Maven Life Cycle phase gives the order of goals and information about the packaging type in a
project.
The build Maven Life Cycle is divided into 3 types, they are:

1. Default Lifecycle
2. Clean Lifecycle
3. Site Lifecycle

The above listed life cycles are independent of each other. Maven can execute more than one build
life cycle at a time but the lifecycles should be executed in a sequence. At the same time, they should
be defined as two separate commands in Maven.
Build Maven Life Cycle is initially grouped into build phase sequence and later build phases are again
divided into build goals.
One can execute the entire build life cycle as “clean” or “site”, otherwise, the default life cycles-
“install” or copy dependency of build goal gets executed. Remaining build phases have to be
executed.

Maven Terminology
Archetype: Archetype is a model that defines the structure of project. Archetype information has
different types of projects being created, folder structure and the information about projects.
Maven initially generates archetype and gets all the required information about the project being
done.

When mvn archetype:generate command is run in the command prompt for the first time, all
the plug-ins are downloaded and gives the list of archetypes and information about the application.
The inputs given to the archetype are classified into 5 types.

 Archetype
 Group ID
 Artifact ID
 Version
 Package

• Archetype: Archetype is the information given to Maven about the type of

project needed. Archetypes will differ based on the application to be developed. There
are archetypes for J2EE applications, spring applications, hibernate applications, etc. in
Maven Repository. Each archetype is a good starting point for each application.

• Artifact ID: Artifact ID is used to identify the output files like jar, war or ear files.

• Group ID: Group ID is an explanatory ID used to group all the artifact ID’s and gives an
identification to it.

• Version: Version has default snapshots, which is a piece of code to be released.

• Package: Package is the location of source code. Based on the inputs provided, the java
class in that archetype will be assigned to a Java class

PROJECT OBJECT MODEL (POM)

The heart of a Maven 2 project, the POM, describes our project, its structure, and its dependencies. It
contains a detailed description of project, including information about versioning and configuration
management, dependencies, application and testing resources, team members and structure, and
much more.
The POM takes the form of an XML file (called pom.xml by default), which is placed in project home
directory. Maven standardizes directory structure. Hence, we would not need to declare source and
target directories.

PROJECT DESCRIPTION
At the start of each Maven POM file, we will find a list of descriptive elements describing things like
the project name, version number, how it is to be packaged, and so on as shown below:
#pom.xml
  The <modelVersion> element declares to which version of project descriptor this POM
conforms.
 The <groupId> element denotes a universally unique identifier for a project. By convention,
it often corresponds to the initial part of the Java package used for the application classes
(eg: edu.mycompany.accounting). When the artifact is deployed to a Maven repository, the
groupId is split out into a matching directory structure on the repository. (eg.
edu\mycompany\accounting).
 The <artifactId> represents the actual name of the project. This, combined with the groupId,
should uniquely identify the project.
 Every project also has a <version> element, which indicates the current version number,
which refers to major releases. Each version has its own directory on the Maven repository,
which is a subdirectory of the project directory.
 The <packaging> element specifies different deliverable file formats such as .jar, .war, .ear,
.pom, etc. For example, in this listing, Maven will generate a file called accounting-core-
1.1.jar.

Maven Repositories
Exactly where Maven looks for dependencies will depend on how our repositories are set up.
There are 3 types of repositories in Maven.
1. Local Repository
2. Central Repository
3. Remote Repository
The default Maven repository is located at http://repo1.maven.org/maven2 (it is defined in the
Super POM file located at
%MAVEN_HOME%\lib\maven-model-builder-3.0.3.jar)

Other popular repositories are:

1) http://repository.jboss.org/nexus/content/groups/public/.
2) http://mvnrepository.com/
The searching sequence of dependencies in the above repository will be the same. Initially, in
local repository, the next in central and then in remote repositories if given in POM file

Local Repository: Local repository contains the downloads of dependencies. Downloading one
is enough even if there are multiple projects. Own projects can be developed in the local
repository using the install command. Local repository is placed in user’s home directory by
default. The location can also be changed using settings.xml.

Central Repository: By default, Maven searches for Central repository for dependencies. There
is no special setup required to use the central repository.

Remote Repository: Remote repository downloads the dependencies from a web server. It can
be anywhere on the internet and even inside the local network. This repository helps in sharing
the projects among the organization. To configure the remote repository in POM files, please
follow the below code:

• Note : Maven always checks for dependencies in the Local  Central  Remote.

DEPENDECY MANAGEMENT
Dependency management is a major feature of Maven . In Maven, JAR files are rarely, if ever, stored
in the project directory structure. Instead, dependencies are declared within the pom.xml file.
Dependencies are the libraries we need to compile, test, and run our application. In a Maven project,
we list the libraries our application needs, including the exact version number of each library. Using
this information, Maven will do its best to find, retrieve, and assemble the libraries it needs during
the different stages in the build lifecycle. In addition, using a powerful feature called Transitive
Dependencies, maven will include not only the libraries that we declare but also all the extra
libraries that our declared libraries need to work correctly.

DECLARING DEPENDENCIES
In the <dependencies> section of the POM file, we declare the libraries that we need to compile,
test, and run our application. Dependencies are retrieved from local or remote repositories, and
cached locally on our development machine, in the C:\Users\Adminstrator\.m2\repository
directory structure (This location is specified in %MAVEN_HOME%\conf\settings.xml file). If we use
the same jar in two projects, it will only be downloaded (and stored) once, which saves time and
disk space.
In Maven, dependencies are handled declaratively.
Example: Suppose that our project needs to use Hibernate.

If we tell Maven that our project needs a particular library, it will try to work out what other libraries
this library needs, and retrieve them as well is called as Transitive Dependencies.

DEPENDENCY SCOPE
We may not need to include all the dependencies in the deployed application. Some JARs are needed
only for unit testing, while others will be provided at runtime by the application server. Using a
technique called dependency scoping, Maven 2 lets us use certain JARs only when we really need
them and excludes them from the classpath when we don’t. Maven provides several dependency
scopes.
The default scope is the compile scope. Compile-scope dependencies are available in all phases.

A provided dependency scope is used to compile the application but will not be deployed. We would
use this scope when we expect the JDK or application server to provide the JAR. The servlet APIs are
a good example:
 The runtime dependency scope is used for dependencies that are not needed for compilation, only
for execution, such as Java Database Connectivity (JDBC) drivers:

We use the test dependency scope for dependencies that are only needed to compile and run tests,
and that don’t need to be distributed (JUnit or TestNG, for example):

PROPRIETARY DEPENDENCIES (Third party Dependencies)

For commercial and copyright reasons, not all of the commonly used libraries are available on the
public Maven repositories. A common example is the Oracle JDBC Driver, which is available free-of-
charge on the Oracle web site, but it cannot be redistributed via a public Maven repository. Before
downloading (manually) these libraries we required to accept license agreement.
Such proprietary libraries like these will need to add it manually to our local repository using mvn install
Command.
Project Creation
While creating any project, users should create an archetype first. An archetype is a tool used to
create other things of the same kind. So, initially create archetype plug-in. For that, the
user should create a folder in any drive (here D:MavenProject is taken) and enter the below
command in command prompt and click on enter.

 GroupId – specifies unique identifer of the organization (Generally company domain name
will be used)
 ArtifactID – Used to specify project name
 ArchetypeArtifactID – While creating the Java project, this template will be used
 InteractiveMode – Normally, this mode is set to true to scan the remote repositories

The following window appears asking for inputs such as

Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 725: 725 (Enter
725 as shown)

Finally when enter button is clicked, the following output appears.

A JavaSamples folder will be created. The following structure appears

Build Lifecycle Basics

Maven is based around the central concept of a build lifecycle. What this means is that the
process for building and distributing a particular artifact (project) is clearly defined.
For the person building a project, this means that it is only necessary to learn a small set of
commands to build any Maven project, and the POM will ensure they get the results they
desired.
There are three built-in build lifecycles: default, clean and site. The default lifecycle handles your
project deployment, the clean lifecycle handles project cleaning, while the site lifecycle handles
the creation of your project's site documentation.
 A Build Lifecycle is Made Up of Phases
Each of these build lifecycles is defined by a different list of build phases, wherein a build phase
represents a stage in the lifecycle.
For example, the default lifecycle comprises of the following phases (for a complete list of the
lifecycle phases, refer to the Lifecycle Reference):

 validate - validate the project is correct and all necessary information is available
 compile - compile the source code of the project
 test - test the compiled source code using a suitable unit testing framework. These tests
should not require the code be packaged or deployed
 package - take the compiled code and package it in its distributable format, such as a
JAR.
 verify - run any checks on results of integration tests to ensure quality criteria are met
 install - install the package into the local repository, for use as a dependency in other
projects locally
 deploy - done in the build environment, copies the final package to the remote
repository for sharing with other developers and projects.

Maven Eclipse Integration

Maven tool is provided by default in all the latest versions of Eclipse. To install the Maven tool in
Eclipse, one should follow the below steps:
Open Eclipse and go to Help -> Eclipse Marketplace and search for maven integration as shown
in the below image.

Find out the plug-in as per the Eclipse IDE and click on Install.
Now, select the required Features and accept the licence agreement. Click on Finish and restart
the Eclipse
Check the Maven Plug-in installation as shown below.

Procedure to work with Maven in Eclipse

Step-1: Launch Eclipse and Select workspace

Step-2: It opens welcome page, if you are accessing this work space first time.
Close welcome page and Navigate to Project Explorer.
Step-3: Right click on Project Explorer and select New  Project
Step-4: It opens New Project Window, Search for Maven and select Maven
Project from search results.

Step-5: It opens New Maven Project window, check create a simple project
check box and click on Next
The following window appears asking to enter the details of Group id, Artifact
id, Version and Packaging. Enter the necessary details of project and click on Finish.

The project structure appears with pom files, target folders, src folder, etc. in project explorer
index as shown below.

Step-7: This will create a project directory structure as shown below.

 Source code (.java files)
Properties and xml files
JUnit Test cases
JUnit related properties and xml files

Maven configuration file

Step-8: Configure required libraries or jar files in pom.xml as dependencies

Step-9: Run maven install command - Right Click on Project

Step-10: If everything works fine, you can see build success message on
console
After build got success, we can verify Configured dependencies (libraries) are
added to your project as shown below.

======0=====