What is a Maven Lifecycle

Like ANT, Maven is a tool to support the build process of a project. Since Maven, like Ant, is developed by the Apache Software Foundation, this is a free build tool. However, the architecture of Maven is fundamentally different from the Ant architecture. An Ant build script is made up of a number of targets that implement the individual build goals. Any number of targets can be used and named for this. With the development of Maven, problems such as the unrecognizable build process for an Ant script as well as the reuse of certain goals should be solved. The implementation effort should therefore be greatly reduced for the processes.
The fundamental difference between Maven and Ant is the philosophy of the approaches. Maven is based on a model-based, declarative approach to realizing the build process. Instead of implementing the individual build goals as with Ant, a so-called project model (mostly) only describes the metadata of the project. The metadata includes information about the project structure used and the specification of the external libraries. Thus the fundamental difference between the two tools is known. In the case of an Ant-controlled process, the developer has to develop a lot himself, whereby he is then offered all freedom and possibilities. Maven, on the other hand, relies on a number of assumptions that determine the course of the build process. This restricts the freedom of design in a Maven build process, but offers the developer a high level of reuse and less effort.

Maven in the CSI environment

As described in the previous section, Maven is a build tool for mapping automated build processes. Version 2.2.1 of Maven was selected in this context to check the automatability of the test tools. The automation function is very important in the context of CSI. There are a number of different test tools that are to be examined with the help of Maven with regard to automation. The question arises as to what support the examined test tools offer when considering automation. The first evaluations of the test tools have shown that well-known test tools such as JUnit, TestNG or jMock offer good support from Maven. So-called plugins are available for use. However, there is no support for all test tools, as some test tools define their own style for analyzing the tests. This makes it difficult to determine and document the information obtained from the tests with Maven.

installation

The installation of Maven is briefly described in the readme of the downloaded archive. To do this, the current Maven version must first be downloaded from the homepage. The downloaded archive is then extracted at any point. Finally, the path to the Maven bin directory should be included in the PATH environment variable in the shell's search path. A current JDK must be installed on the computer as a prerequisite. To check the installation, the command can be carried out via the console. It should also be noted that the local Maven repository is automatically stored in the user directory. If another directory is to be used for this, the following element must be changed in the settings.xml (directory conf in the installation directory of Maven):

architecture

The following figure is intended to show the architecture of Maven. The project model in the project directory is the central configuration point for defining the build process. The existing dependencies are resolved via the local repository. If the required external libraries are not available in the local repository, they are automatically downloaded from the remote repository if possible.

After installing Maven, only the compact core is on the computer. This is only able to interpret the project model. The individual build processes are implemented using a number of plugins. When using Maven for the first time, this leads to a somewhat longer download of all required standard plugins at the beginning. This process is carried out fully automatically by Maven.

Maven repository

Different repositories are available with Maven. On the one hand, the local repository is used to resolve the defined external libraries. All existing dependencies for a project model are downloaded into this repository, making it the first point of contact for the Maven build process. If the existing dependency for the build process could not be resolved in the local repository, the remote repository is automatically queried and the required libraries are downloaded. It is also possible to enter your own libraries in the local repository; this also applies to publication in the remote repository. The following command can be executed to quickly and easily transfer an external library to the local repository:
This command causes the selected library to be entered in the local repository. The external library can then be linked to the project model via the element. The element is a Maven-specific element to define dependencies on external libraries. The meaning of the groupID and artifactID is explained in the following section.

Structure of the project model

In contrast to Ant, Maven is based on a declarative approach. The build process is not implemented in the project model, only the metadata of the project is described. The general structure of a project model should be shown in the following figure:

The project model is an XML document that is called by default. In order to be able to go into the structure and content of the project model in more detail below, a pom.xml should be shown as an example. In the first part of the general information about the project is given. Some information should always be given for better understanding. These elements are briefly described below:
  • modelVersion: Version of the Maven project model. This depends on the Maven version used.
  • groupId: Unique identification of the manufacturer. Best Practice: Manufacturer's domain name in reverse order.
  • artifactId: Name of the artifact to be created. The ID is the basis for the later delivery name.
  • version: Version of the project or artifact.
  • name, description, url: Self-explanatory, general information about the product.
In the following, project-specific paths can be specified using the element. If no properties are explicitly specified, Maven makes certain assumptions. This is an important point and should be considered as a newcomer. As a newcomer, you should first work with the standard Maven paths, as far as possible. As a small reference for the standard paths, reference is made to the standard listing from Maven.
The element defines the project structure. On the one hand, the directories in which the sources are to be defined must be defined. On the other hand, all destinations in which the compiled sources and files are to be saved must also be specified. Please note that when specifying the directories, a distinction must be made between normal directories such as and test directories such as . Since Maven is a declarative approach and therefore works with many assumptions, the test sources must be in the correct directory or the changes must be explicitly made known to Maven.
In the last section of pom.xml, the existing dependencies on external libraries are defined. In this example, a dependency on the JUnit library is defined. This must be available in the local repository or is automatically transferred from the remote repository to the local one. The groupId, artifactId and the version must be specified for definition. The last element defines the area in which the dependency is required. In this case the area was set to. This setting means that the JUnit library is required when executing the test cases.

The Maven Build Lifecycle

A Maven build lifecycle is described by a number of standard build phases. A parameter can be used to select the phase up to which the build process should be processed. Since the individual phases build on one another successively, all previous phases are also run through. To complete the subject, reference should be made to the Maven homepage, which lists and briefly explains the entire build life cycle. Each individual build phase in the life cycle is implemented with the help of plugins and can therefore also be set individually. In addition, the specific phase can be controlled via a console parameter. Entering z. B. causes the build process to perform up to the stage. If certain plugins for a phase are not available in the local repository, they are automatically loaded from the remote repository.

Finding dependencies

Since most projects always have a lot of dependencies on external libraries, Maven offers the management of these in a local repository. In order not to manually load every external library into the repository, Maven continues to offer the remote repository in which many standard libraries such as JUnit are located. In order to keep an overview of the entire set of dependencies, there are so-called search engines for the Maven repository. When working on this topic, this website was used more frequently to search for external libraries.

Tips for newcomers

Maven is a powerful tool that uses a declarative approach. Thus, Maven automatically makes assumptions that are not necessarily familiar and known to the newcomer. To get a good introduction to how Maven works, we recommend the Maven-in-5-Minute tutorial provided by Maven. This short tutorial creates a simple Java project with the external dependency on JUnit.

Back to the tool overview
Back to the CSI main page