MAVEN basics

Installing Apache Maven

The installation of Apache Maven is a simple process of extracting the archive and adding the bin folder with the mvn command to the PATH.

Detailed steps are:

JAVA_HOME environment variable is set and points to your JDK installation


Add the bin directory of the created directory apache-maven-3.3.3 to the PATH environment variable,change your file of /etc/profile to add :

        export PATH=/opt/apache-maven-3.3.3/bin:$PATH

and also run this command too, then run this command to confirm installed in a new console
        mvn -v

create a sample project and to learn it

    cd /temp

    mvn archetype:generate -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
cd my-app
mvn package
java -cp target/my-app-1.0-SNAPSHOT.jar

Although hardly a comprehensive list, these are the most common default lifecycle phases executed.

  • 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.
  • integration-test: process and deploy the package if necessary into an environment where integration tests can be run
  • 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.

There are two other Maven lifecycles of note beyond the default list above. They are

  • clean: cleans up artifacts created by prior builds
  • site: generates site documentation for this project

This is a very simple POM but still displays the key elements every POM contains, so let’s walk through each of them to familiarize you with the POM essentials:

  • project This is the top-level element in all Maven pom.xml files.
  • modelVersion This element indicates what version of the object model this POM is using. The version of the model itself changes very infrequently but it is mandatory in order to ensure stability of use if and when the Maven developers deem it necessary to change the model.
  • groupId This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example org.apache.maven.plugins is the designated groupId for all Maven plug-ins.
  • artifactId This element indicates the unique base name of the primary artifact being generated by this project. The primary artifact for a project is typically a JAR file. Secondary artifacts like source bundles also use the artifactId as part of their final name. A typical artifact produced by Maven would have the form <artifactId>-<version>.<extension> (for example, myapp-1.0.jar).
  • packaging This element indicates the package type to be used by this artifact (e.g. JAR, WAR, EAR, etc.). This not only means if the artifact produced is JAR, WAR, or EAR but can also indicate a specific lifecycle to use as part of the build process. (The lifecycle is a topic we will deal with further on in the guide. For now, just keep in mind that the indicated packaging of a project can play a part in customizing the build lifecycle.) The default value for the packaging element is JAR so you do not have to specify this for most projects.
  • version This element indicates the version of the artifact generated by the project. Maven goes a long way to help you with version management and you will often see the SNAPSHOT designator in a version, which indicates that a project is in a state of development. We will discuss the use of snapshots and how they work further on in this guide.
  • name This element indicates the display name used for the project. This is often used in Maven’s generated documentation.
  • url This element indicates where the project’s site can be found. This is often used in Maven’s generated documentation.
  • description This element provides a basic description of your project. This is often used in Maven’s generated documentation.
With this information about a dependency, Maven will be able to 
reference the dependency when it builds the project. Where does Maven 
reference the dependency from? Maven looks in your local repository (~/.m2/repository is the default location) to find all dependencies. 

What about dependencies built somewhere else? How do they get into my 
local repository? Whenever a project references a dependency that isn't 
available in the local repository, Maven will download the dependency 
from a remote repository into the local repository. 

Let’s add another dependency to our project. Let’s say we’ve added some logging to the code and need to add log4j as a dependency. First, we need to know what the groupId, artifactId, and version are for log4j. We can browse ibiblio and look for it, or use Google to help by searching for “ maven2 log4j”.

The search shows a directory called /maven2/log4j/log4j (or /pub/packages/maven2/log4j/log4j). In that directory is a file called maven-metadata.xml. Here’s what the maven-metadata.xml for log4j looks like:

    1. <metadata>


  • <groupId>log4j</groupId>
  • <artifactId>log4j</artifactId>
  • <version>1.1.3</version>
  • <versioning>
  • <versions>
  • <version>1.1.3</version>
  • <version>1.2.4</version>
  • <version>1.2.5</version>
  • <version>1.2.6</version>
  • <version>1.2.7</version>
  • <version>1.2.8</version>
  • <version>1.2.11</version>
  • <version>1.2.9</version>
  • <version>1.2.12</version>
  • </versions>
  • </versioning>
  • </metadata>