This blog will deliver a technical overview of Maven and its uses. Before moving forward to maven let us know what are Build Tools and its uses.
What are Build tools?
Build tools are programs that automate the creation of executable applications from source code (eg. .apk for the Android app). The building incorporates compiling, linking and packaging the code into a usable or executable form. The 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:
- Compiling source codes into binary code.
- Packaging that binary code.
- Running tests.
- Deployment to production systems.
- Creating documentation and release notes.
Why do we use build tools or build automation?
In smaller 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. Use of an automation tool allows the build process to be more consistent.
Build tools which can be used for different types of languages:
- For Java – Ant, Maven, Gradle.
- For .NET framework – NAnt
- For c# – MsBuild.
Now, we have got to know what are build tools and its uses. Let us know how Maven got introduced.
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 previously and every ant build appeared to be different and they found it as complex and futile. So, Apache then developed and introduced Maven in March 2002 which can work, build, deploy, share dependencies between multiple projects at the same time. Currently, the latest version available is Maven3.
What is Maven?
Maven is a project Management and comprehension tool, which manages a project’s build, reporting, and documentation from a central piece of information.
As a powerful build tool, maven can do the following things
Now we got to know the working of Maven, let us continue with Maven Installation.
To install Maven, Java should be pre-installed on the local system.
Download Maven from the below link:
- 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 installation path.
Windows – Goto system properties and set the below values
M2_HOME=C:\Program Files\Apache Software Foundation\apache-maven-3.3.9
Linux – Open a terminal and set environment variables by using the below commands.
Mac – Open a terminal and set environment variables by using the below commands.
Once the things are done, you can check the existence of maven by using the below commands:
- Windows – Open command prompt and type mvn –version
- Linux – Open a terminal and type mvn –version
- Mac – Open a terminal and type mvn –version
So everything is setup 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
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 the 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
A POM requires that its groupId, artifactId, and version be configured. These three values from the project are 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
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 of 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
- To 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.
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
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
[INFO]------------------------------------------------------------------------[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------[INFO] Total time: 2 seconds[INFO] Finished at: Thu Jul 07 21:34:52 CEST 2011[INFO] Final Memory: 3M/6M[INFO] ------------------------------------------------------------------------
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:
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
-Integrating with IDE’s
-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 a hierarchical structure of the project
These are the certain 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 Big Data and other technologies.