Introduction to Apache Maven

In this blog we will be discussing about maven, how it works and why it is famous for. Let’s come from the History of Maven.

History of Maven

The word maven means “accumulator of knowledge” in Yiddish. Maven began its life in the Jakarta Alexandria project.Though Maven started in Alexandria the test bed for its use was the Turbine project.There was no way to easy template Ant builds in those days and every ant build appeared to be different and they found this incredibly frustrating and futile. People in Apache then developed Maven which can work on multiple projects at the same time. It can build Multiple projects at the same time, deploy multiple projects at the same time and also share the dependencies between several projects at the same time. The first version of Maven i.e., Maven1 is released in 2002-03-30. Now the latest version is Maven3.

Now let’s come to what maven is

What is Maven?

Maven is a project Management tool simply it is called as a Build tool. So what is Build tool?

What is a Build tool?

Build tools are programs that automate the creation of executable applications from source code(eg. .apk for android app). Building incorporates compiling,linking and packaging the code into a usable or executable form.
Basically build automation is the act of scripting or automating a wide variety of tasks that software developers do in their day-to-day activities like:

1. compiling source code into binary code.
2. Packaging that binary code.
3. Running tests.
4. Deployment to production systems.

Why do we use build tools or build automation?

In small projects, developers will often manually invoke the build process. This is not practical for larger projects, where it is very hard to keep track of what needs to be built, in what sequence and what dependencies there are in the building process. Using an automation tool allows the build process to be more consistent.
There are different types of Build tools available for different types of langugages. For example
For java – Ant,Maven,Gradle.
For .NET framework – NAnt
For c# – MsBuild.
So Maven is a Build tool for java applications. So to work on Maven Java needs to be installed in your system.
Let’s see what maven can do.
As a powerful build tool, maven can do the following things
-Build
-Documnet
-Dependency Management
-Distributions
-Test
-Report
-SCM’s
-Releases
Now let’s move on to the installation of Maven
Maven Installation
To install maven Java needs to be installed in your system.
Download Maven from the below link:
http://maven.apache.org/download.cgi
Windows – apache-maven-3.3.9-bin.zip
Linux – apache-maven-3.3.9-bin.tar.gz
Mac – apache-maven-3.3.9-bin.tar.gz
After downloading install the Maven, After the extraction set the environment variables. The installation paths by default can be as follows:
Windows – C:\Program Files\Apache Software Foundation\apache-maven-3.3.3
Linux – /usr/local/apache-maven
Mac – /usr/local/apache-maven
Now you need to set the environment variables based on your intallation path.

Windows – Move into the system properties and set the below values

M2_HOME=C:\Program Files\Apache Software Foundation\apache-maven-3.3.9

M2=%M2_HOME%\bin

Linux – Open the terminal and set environment variables by using the below commands.

export M2_HOME=/usr/local/apache-maven/apache-maven-3.3.9

export M2=$M2_HOME/bin

Mac – Open the terminal and set environment variables by using the below commands.

export M2_HOME=/usr/local/apache-maven/apache-maven-3.3.3

export M2=$M2_HOME/bin

Once the things are done, you can check the existence of maven by using the below commands:

Winodows – Open command propmt and type mvn –version

Linux – Open the terminal and type mvn –version

Mac – Open the terminal and type mvn –version

So everything is set up for building your project through Maven, now what Maven needs for building your project?

What all maven needs is an xml file, that xml file is called as pom which stands for Project Object Model

What is POM file?

The pom.xml file is the core of a project’s configuration in Maven. It is a single configuration file that contains the majority of information required to build a project in just the way you want. The POM is huge and can be daunting in its complexity, but it is not necessary to understand all of the intricacies just yet to use it effectively.

A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information about the project and configuration details used by Maven to build the project. It contains default values for most projects. Examples for this is the build directory, which is target; the source directory, which is src/main/java; the test source directory, which is src/test/java; and so on.

The POM was renamed from project.xml in Maven 1 to pom.xml in Maven 2. Instead of having a maven.xml file that contains the goals that can be executed, the goals or plugins are now configured in the pom.xml. When executing a task or goal, Maven looks for the POM in the current directory. It reads the POM, gets the needed configuration information, then executes the goal.

Some of the configuration that can be specified in the POM are the project dependencies, the plugins or goals that can be executed, the build profiles, and so on. Other information such as the project version, description, developers, mailing lists and such can also be specified.

The minimum requirement for a POM are the following:

• project root

• modelVersion – should be set to 4.0.0

• groupId – the id of the project’s group.

• artifactId – the id of the artifact (project)

• version – the version of the artifact under the specified group

For Example

A POM requires that its groupId, artifactId, and version be configured. These three values form the project’s fully qualified artifact name. This is in the form of <groupId>:<artifactId>:<version>. As for the example above, its fully qualified artifact name is “com.mycompany.app:my-app:1”.

Also, as mentioned in the first section, if the configuration details are not specified, Maven will use their defaults. One of these default values is the packaging type. Every Maven project has a packaging type. If it is not specified in the POM, then the default value “jar” would be used.

Furthermore, as you can see that in the minimal POM, the repositories were not specified. If you build your project using the minimal POM, it would inherit the repositories configuration in the Super POM. Therefore when Maven sees the dependencies in the minimal POM, it would know that these dependencies will be downloaded from http://repo.maven.apache.org/maven2 which was specified in the Super POM.

For more details you can refer to the apache site
http://maven.apache.org/guides/introduction/introduction-to-the-pom.html

Super POM

The Super POM is Maven’s default POM. All POMs extend the Super POM unless explicitly set, meaning the configuration specified in the Super POM is inherited by the POMs you created for your projects.

Building through Maven

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.

These lifecycle phases (plus the other lifecycle phases not shown here) are executed sequentially to complete the default lifecycle. Given the lifecycle phases above, this means that when the default lifecycle is used, Maven will first validate the project, then will try to compile the sources, run those against the tests, package the binaries (e.g. jar), run integration tests against that package, verify the integration tests, install the verified package to the local repository, then deploy the installed package to a remote repository.

Usual Command Line Calls

In a development environment, use the following call to build and install artifacts into the local repository.

mvn install

This command executes each default life cycle phase in order (validate, compile, package, etc.), before executing install. You only need to call the last build phase to be executed, in this case, install:

In a build environment, use the following call to cleanly build and deploy artifacts into the shared repository.

mvn clean deploy

The same command can be used in a multi-module scenario (i.e. a project with one or more subprojects). Maven traverses into every subproject and executes clean, then executes deploy (including all of the prior build phase steps).

You can refer to the apache site for in-detailed explanation about life cycle building using maven

https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

After adding all the dependencies, your project is ready for build, for building the project you just need to issue the command mvn package in your project directory where the pom.xml file is present.

After the successful build, you will get a message like

Unlike the first command executed (archetype:generate) you may notice the second is simply a single word – package. Rather than a goal, this is a phase. A phase is a step in the build lifecycle, which is an ordered sequence of phases. When a phase is given, Maven will execute every phase in the sequence up to and including the one defined. For example, if we execute the compile phase, the phases that actually get executed are:

1. validate
2. generate-sources
3. process-sources
4. generate-resources
5. process-resources
6. compile

Now let’s talk about why maven is famous.

Despite of being an Apache project, maven has its own feature which make it stand top in the industry.

Why maven is famous for?

Here are some of the features of Maven which made it famous!

-Java based tool

-Integrationg with IDE’s

-Hirerachy management

-Dependency management

-Easy to deploy the projects using maven

-Easy compilation of the code using maven

-Easy to test and debug using maven

-Uses an xml file for build management which maintains an hierarchial structure of the project

These are some of the reasons which made maven famous. There are a lot more with Maven.

We hope this blog helped you in understanding Maven, Keep visiting our site www.acadgild.com more updates on Bigdata and other technologies.