Install Maven in Ubuntu

What is Maven?

Maven is a tool of build automation used mainly for Java projects. Also, it can be used for building and managing projects which are written in is Scala, Ruby, C#, and other languages. The project of Maven is hosted via the Apache Software Foundation, in which it was the Jakarta Project part.

Maven defines two aspects of establishing software: how software is established and its dependencies. It applies conventions for the establishment procedure, unlike earlier tools such as Apache Ant. Only exceptions are required to be described. An XML file defines the software project being established and its dependencies on many other external components and modules, the build directories, order, and required plug-ins. It provides the pre-defined code and packaging.

Dynamically, Maven downloads Maven plugins and Java libraries from multiple repositories like the Maven 2 Central Repository and saves them in the local cache.
Also, this local cache of installed artifacts can be updated with many artifacts made by local projects.
Also, public repositories can be updated.
Maven is created with the plug-in architecture that permits it for making use of an application that is controllable from standard input.
The native plug-in of C/C++ is organized for Maven 2.
Many alternative technologies such as sbt and Gradel, because build tools don't depend on XML, but have the key concepts that Maven introduced.
A dependency manager was developed that supports the repositories of Maven as well with Apache Ivy.

History of Maven

Maven was established by Jason van Zyl and started in 2002 as the Apache Turbine sub-project. It was voted on and adopted as a top-level project Apache Software Foundation in 2003. The release of Maven was the demanding first milestone, v1.0, in July 2004. In October 2005, Maven 2 was announced v2.0 after about 6 months in its beta cycles. In October 2010, Maven 3.0 was published, being particularly backward compatible with the 2^nd version of Maven.

In 2018, Maven 3.0 information started trickling out. In April 2010, the first Maven 3.0 beta version was published after 8 alpha versions. Maven 3.0 has reconstituted the core Project Builder infrastructure providing the file-based representation of POM being decoupled through its in-memory object representation. It has increased the possibility for the add-ons of Maven 3.0 to take advantage of non-XML-based project definition files. Suggested languages include Groovy, YAML, and Ruby.

Special attention was provided to guarantee Maven 3 backward compatibility with Maven 2.
For almost all projects, switching to Maven 3 will not need their project structure adjustments.
The first Maven 3 beta version saw the parallel build aspect introduction, which leverages any configurable count of cores on a machine (multi-core) and is particularly suited for bigger multi-module projects.

Interoperability of Maven

Add-ons to various famous IDE (Integrated Development Environments) targeting Java exist to offer Maven integration with the source editing and build mechanism tools of IDE, permitting Maven to arrange projects from inside the IDE, and to configure the code completion classpath, focusing compiler errors, etc.
Some examples of famous IDEs support development using Maven are:

Visual Studio Code
MyEclipse
JDeveloper
JBuilder
IntelliJ IDEA
NetBeans
Eclipse

Also, these add-ons offer the ability to utilize the POM or alter the POM to decide the complete set of a project of dependencies within the IDE directly. A few built-in aspects of IDEs are absent when the IDE does not perform compilation anymore. For instance, the JDT of Eclipse can recompile an individual Java source file when it has been altered. Several IDEs operate with a flat group of projects rather than the folder hierarchy approved by Maven. It complicates the utilization of SCM systems when utilizing Maven in IDEs.

Objectives of Maven

The primary goal of Maven is to permit a developer to assimilate the development effort's complete state in the shortest time. Maven deals with many areas of concern to attain this aim:

Make the build process easier: Maven does not eliminate the requirement to know about the basic mechanisms when using Maven. Maven does protect developers from several details.
Encouraging development practices: Maven focuses on collecting current rules for best development practices and makes it convenient to instruct a project in that way.
For instance, unit test specification, implementation, and reporting are part of the common build cycle with Maven. Some best practices for current unit testing were applied as guidelines:
- Including test cases that structure their environment rather than customizing the creation for test preparation.
- Using the naming conventions of test cases to locate and run tests.
- Keeping the source code of the test in an isolated, although parallel source tree.
Also, Maven helps in project workflow, like issue and release management.
Also, Maven recommends a few guidelines on how to design the directory structure of our project. When we learn the design, we can easily manage other projects that are using Maven.
A few projects might not fit in this structure, while Maven considers an opinionated approach for project design. While Maven is created to be extensible to be requirements of several projects, it can't cater to all circumstances without disturbing its objectives.
Giving a reliable build system: Maven creates a project with its POM (Project Object Model) and a group of plug-ins. When we familiarize ourselves with a single Maven project, we know how every Maven project creates. It saves time during navigation with various projects.
Giving quality project details: Maven offers helpful project information that's in part taken through our POM and produced from the sources of our project. For instance, Maven can offer the following:
- Unit test details such as coverage.
- Dependencies utilized by the project.
- Mailing lists handled by the project.
- Cross-referenced sources.
- Change log made from source control directly.

Also, third-party code analysis offers Maven plug-ins that include their reports in the typical information provided by Maven.

Features of Maven

The following are some important features of Maven:

Easy project setup that pursues best practices- a new module or project can be initiated in seconds.
Persistent usage around every project. It means there is no ramp-up period for new developers arriving on a project.
Dependency management, such as dependency closures (also called transitive dependencies) and automatic updating.
Can easily operate with two or more projects simultaneously.
A growing and large repository of metadata and libraries to utilize out of the box, and provisions in place along with the biggest Open-Source projects for the availability of their recent releases.
Instant access to several aspects with no or little extra configuration.
Extensible with the capability to write plugins in scripting or Java languages easily.
Ant operations for dependency deployment and management external to Maven.
Maven includes model-based builds as it can create several projects into many pre-specified output types, including distribution, WAR, or JAR, based on project metadata, without the requirement to implement scripting in almost all cases.
Maven can produce a PDF or website, such as any documentation we care to include, and includes to that specific report about the development state of the project with similar metadata to the build process. This information's examples can be checked at the bottom of the left-side navigation of the site upon the "Project Reports" and "Project Information"
Maven will coordinate with our source control system (like Git or Subversion) and handle a project release based on certain tabs without much extra configuration. Also, it can release it to a distribution location for utilization by other projects. Maven can release individual output, including a source distribution and JAR, which is an archive having documentation and other dependencies.
Maven encourages the utilization of central JAR repositories and other dependencies. It provides a mechanism that the clients of our project can apply to download the JARs necessary to build our project with a central JAR repository almost similar to Perl's CPAN. It permits Maven users to use JARs again around projects and develops project communication to make sure that backward compatibility problems are dealt with.

Design of Maven

Project Object Model (POM)

A project object model facilitates every configuration for one project. The basic configuration covers the name of the project, its dependencies, and its owner on other projects, Also, one can configure a single phase of a build process, which is worked as plugins. For instance, one can construct the compiler plugin for using the 1.5 version of Java for compilation or describe the project packaging even when a few unit tests break down.

Bigger projects should be categorized into many sub-projects and modules, each with its POM. Then, one can specify a root POM from which one can compile every module with one command. Also, POMs can acquire configuration from any other POM. Every POM by default acquires from its super POM. The super POM gives default configurations like default plugins, default source directories, etc.

POM is short for "Project Object Model". It's a Maven Project's XML representation held inside a file called pom.xml. A project has configuration files, associated developers, a defect tracking system, licenses, organizations, the project URL, dependencies of the project, and every other little part that comes to provide code life. It's a one-stop-shop for everything interested in the project. A project doesn't need to include the code at all, hardly a pom.xml file, in the Maven world.

Maven coordinates

POM is the bare minimum that is allowed by Maven: groupId:artifactId:version is every necessary field (however, version and groupId don't need to be defined explicitly if they're acquired from any parent). These three fields behave much like a timestamp and an address in one. It marks a particular place within a repository, behaving like a coordinate system:

groupId: Generally, it is unique over a project or an organization. For instance, every core artifact of Maven does live upon the org.apache.maven groupId. Group IDs don't essentially utilize the dot notation, e.g., the junit project. Remember that the dot-noted groupId doesn't need to resemble the package structure that is contained by the project. However, it is a good practice to consider.
The group behaves much like the structure of Java packaging does in an OS saved in a repository. The dots are substituted by operating system separators of a specific directory, which becomes a corresponding directory structure through the base repository. The group, i.e., org.codehaus.mojo, lives with the $M2_REPO/org/codehaus/mojo directory in this instance.
artifactId: Generally, this artifactId is the title that the project is called by. People in the group will specify the groupId within the discussion session (often, they are each a similar ID, like the org.codehaus.mojo MojoHaus project groupId), although the groupId is crucial. With the groupId, it makes a key that isolates this project from all other projects across the world. The artifactId fully specifies the living quarters of the artifact inside the repository with the groupId.
version: It is the final part of the naming puzzle. groupId:artifactId specifies an individual project, but it can't define which project incarnation we are discussing about. Also, it is used in the repository of an artifact to isolate versions.

Plug-ins

Most functionality of Maven is inside the plugins. A plugin gives a group of goals that could be run with the help of the mvn [plugin-name] : [goal-name] command. For instance, a project of Java could be compiled with the compile-goal of compiler-plugin by executing the mvn compiler:compile command.

There are many Maven plugins to build, test, run a web server, source control management, produce Eclipse project files, etc. These plugins are configured and introduced in the section, i.e., <plugins> of the pom.xml file.

A few basic plugins are by default added in all projects and they have logical default settings. It however would be inconvenient if the archetypal build sequence of packaging, testing, and building a software project needed manually executing all respective goals:

mvn compiler:compile
mvn surefire:test
mvn jar:jar

The lifecycle concept of Maven manages this problem.

A plugin is the main way for extending Maven. Integrating a Maven plugin could be implemented by extending a class, i.e., org.apache.maven.plugin.AbtractMojo.

Build lifecycles

It is a named phases list that could be used for giving sequence to goal implementation. One of the standard lifecycles of Maven is a default lifecycle, which has some phases in a particular order, which is mentioned as follows:

Lifecycle 1: validate
Lifecycle 2: generate-sources
Lifecycle 3: process-sources
Lifecycle 4: generate-resources
Lifecycle 5: process-resources
Lifecycle 6: compile
Lifecycle 7: process-test-sources
Lifecycle 8: process-test-resources
Lifecycle 9: test-compile
Lifecycle 10: test
Lifecycle 11: package
Lifecycle 12: install
Lifecycle 13: deploy

Goals given by plugins could be connected with different lifecycle phases. For example, the compiler:compile goal is by default connected with the phase, i.e., compile, while the surefire:test goal is connected with the phase, i.e., test. When the command, i.e., mvn test is run, Maven executes every goal connected with all phases up to and adding the 'test' phase.

Maven executes the goal, i.e., resources:resources connected with the phase, i.e., process-resources, then compiler:compile, etc until it finally executes the goal, i.e., surefire:test.

Also, Maven contains standard phases to clean the project and generate a project site. The project will be cleaned all time it was created if cleaning were the default lifecycle part. It is undesirable, hence cleaning has been provided its lifecycle.

Dependencies

Dependency management is a central aspect of Maven. The dependency-handling mechanism of Maven is organized across a coordinate system recognizing individual artifacts like software models or libraries.

Installing Maven in Ubuntu 20.04

Apache Maven is an exclusive and advanced tool in the creation of projects typically corresponding to Java. It's an open-source tool that uses the Project Object Model encompassing an XML file for retailing the crucial information of a project, that culminates within the information related to the art project, configuration files, and its dependencies.

We will require common knowledge over the commands and working of Linux, sudo commands recognizing, and the root user privileges for effectively installing Maven on the 20.04 version of Ubuntu. This tool is created for assisting its user in creating projects by reporting and documenting the central project regarding information proficiently.

Maven qualifies as a best-suited tool to manage Java projects. Also, it contains built-in object commands for dealing with the code composition and packages.

Installation Process of Maven

The installation process of Maven is short composite on three basic steps. Before starting these three steps, we can avail every benefiting aspect of Maven for managing the Java projects on our Ubuntu system.

Step 1: Package up-gradation

Step 2: Apache Maven installation

Step 3: Verification

Prerequisites

It's mandatory to have Java installed in our server with the Java encompassing JRE and JDK development kit to execute the Maven commands. If we do not have Java installed in our system, then we can run the following command in the terminal window:

Also, we can verify the Java system installation and its kit with the help of the following command:

Step 1: Package up-gradation

First of all, we need to update our existing packages with the help of the sudo apt command. It's fundamental for updating our existing packages before going to install any server or tool on the Ubuntu system. The command is mentioned below:

Also, we can execute this command before going to install the Java kit. The system packages would be updated with the Java kit installation using this way.

Step 2: Apache Maven installation

Primarily, there are two methods to get Maven in our system. Either, we can download it using the apt command or using its web source directly from the wget command.

We need to run the following command in the terminal window to install Maven: