20+ Maven Terminologies that Automation Testers should be Aware Of

Maven is a powerful project management and build automation tool that is used primarily for Java projects. Based on the concept of a project object model (POM), it can manage a project’s build, reporting and documentation from a central piece of information. In continuation to our previous article introducing ‘Maven Build Tool’, this article describes some of the most common terms encountered while using Maven. These terms, that have an explicit meaning for Maven, can sometimes be confusing for newcomers. As an Automation QA, you should at least be aware of the below 20+ Maven terminologies – commonly asked in a technical interview as well.

Maven Project

Maven thinks in terms of projects. Everything that you will build are projects. Those projects follow a well-defined “Project Object Model”. Projects can depend on other projects, in which case the latter are called “dependencies”. A project may consist of several sub-projects, however these sub-projects are still treated equally as projects.

Maven Archetypes | Project Types

Archetypes are templates to create a variety of Java project structures, including web applications specific to a container such as Wildfly. In other words, it is a tool that creates the stuff you build the project on top of. Project Types,

War | Jar | Ear | Wildfly | JMS | Android

Convention over Configuration

Maven uses Convention over Configuration, which means developers are not required to create build process themselves. Developers do not have to mention each and every configuration detail. Maven provides sensible default behavior for projects. When a project is created, Maven creates default project structure. Developer is only required to place files accordingly and he/she need not to define any configuration in pom.xml.

As an example, following table shows the default values for project source code files, resource files and other configurations. Assuming, ${basedir} denotes the project location,

  • Source code: ${basedir}/src/main/java
  • Resources: ${basedir}/src/main/resources
  • Tests: ${basedir}/src/test
  • Complied byte code: ${basedir}/target
  • Distributable JAR: ${basedir}/target/classes


A group ID is a universally unique identifier for a project’s group. This is generally unique amongst an organization or a project. While this is often just the project name (eg. commons-collections), it is helpful to use a fully-qualified package name to distinguish it from other projects with a similar name (eg. org.apache.maven). For example, a banking group com.company.bank has all bank related projects.


This is an Id of the project. This is generally name of the project. For example, testing-studio. Along with the groupId, the artifactId defines the artifact’s location within the repository.


This is the version of the project. Along with the Group Id, It is used within an artifact’s repository to separate versions from each other. For example.

  • company.sts:testing-studio:1.0
  • company.sts:testing-studio:1.1


An artifact is something that is either produced or used by a project. In Maven terminology, the artifact is the resulting output of the maven build, generally a jar or war or other executable file that gets deployed to a repository. Examples of artifacts produced by Maven for a project include: JARs, source and binary distributions, WARs. Artifacts are identified by a coordinate system of groupId, artifactId, and version. Each artifact has a group ID, an artifact ID (just a name), and a version string. A project’s dependencies are specified as artifacts.


Projects can (and should) have a special version including SNAPSHOT to indicate that they are a “work in progress”, and are not yet released. When a snapshot dependency is encountered, it is always looked for in all remote repositories, and downloaded again if newer than the local copy. The version can either be the string SNAPSHOT itself, indicating “the very latest” development version, or something like 1.1-SNAPSHOT, indicating development that will be released as 1.1 (i.e. newer than 1.0, but not yet 1.1).

Snapshot vs Version

In case of Version, if Maven once downloaded the mentioned version, say testing-studio: 1.0, it will never try to download a newer 1.0 available in repository. To download the updated code, testing-studio version is to be upgraded to 1.1. In case of SNAPSHOT, Maven will automatically fetch the latest SNAPSHOT (testing-studio:1.0-SNAPSHOT) every time the team build their project.


A repository in Maven is used to hold build artifacts and dependencies of varying types, i.e. used as a storage folder or a directory where all the project jars, library jar, plugins or any other project specific artifacts are stored and can be used by Maven easily. There are strictly only two types of repositories: local and remote.

  • The local repository refers to a copy on your own installation that is a cache of the remote downloads, and also contains the temporary build artifacts that you have not yet released. Maven local repository command is %USER_HOME%/.m2 directory.
  • Remote repositories refer to any other type of repository, accessed by a variety of protocols such as file:// and http://. These repositories might be a truly remote repository set up by a third party to provide their artifacts for downloading (for example, repo.maven.apache.org and uk.maven.org house Maven’s central repository). Other “remote” repositories may be internal repositories set up on a file or HTTP server within your company, used to share private artifacts between development teams and for releases.

The local and remote repositories are structured the same way so that scripts can easily be run on either side, or they can be synced for offline use.


A typical Java project relies on libraries to build and/or run. Those are called “dependencies” inside Maven. Those dependencies are usually other projects’ JAR artifacts, but are referenced by the POM that describes them.

External Dependency

Maven dependency management uses concept of Repositories (Local, Central, Remote). Suppose dependency is not available in any of remote repositories and central repository; in such scenarios Maven uses concept of External Dependency. External dependencies (library jar location) can be configured in pom.xml in same way as other dependencies.

Project Object Model (POM)

POM stands for Project Object Model. It is fundamental unit of work in Maven. It is an XML file that resides in the base directory of the project as pom.xml. The POM contains information about the project and various configuration detail used by Maven to build the project(s). POM also contains the goals and plugins. While executing a task or goal, Maven looks for the POM in the current directory. It reads the POM, gets the needed configuration information, and then executes the goal. Some of the configuration that can be specified in the POM are following −

Project dependencies | Plugins | Goals | Build profiles | Project version | Developers | Mailing list.

Before creating a POM, we should first decide the project group (groupId), its name (artifactId) and its version as these attributes help in uniquely identifying the project in repository.

<project xmlns = “http://maven.apache.org/POM/4.0.0”

   xmlns:xsi = “http://www.w3.org/2001/XMLSchema-instance”

   xsi:schemaLocation = “http://maven.apache.org/POM/4.0.0







It should be noted that there should be a single POM file for each project. All POM files require the project element and three mandatory fields: groupId, artifactId, version. Projects notation in repository is groupId:artifactId:version.

Build Profile

A Build profile is a set of configuration values, which can be used to set or override default values of Maven build. Using a build profile, you can customize build for different environments such as Production v/s Development environments. Profiles are specified in pom.xml file using its activeProfiles/profiles elements and are triggered in variety of ways. Profiles modify the POM at build time, and are used to give parameters like different target environments (for example, the path of the database server in the development, testing, and production environments). Build profiles are majorly of three types.

  • Per Project: defined in the project POM file, pom.xml.
  • Per User: defined in Maven settings xml file (%USER_HOME%/.m2/settings.xml).
  • Global: defined in Maven global settings xml file (%M2_HOME%/conf/settings.xml)

Maven Build Lifecycle

A Build Life-cycle is a well-defined sequence of phases, which define the order in which the goals are to be executed. Here phase represents a stage in life cycle. When Maven starts building a project, it steps through a defined sequence of phases and executes goals, which are registered with each phase. Maven has the following three standard life-cycles,

  • Clean: cleans up artifacts created by prior builds.
  • Default (or build): used to build the application.
  • Site: generates site documentation for the project.

Maven Phases

In simple terms “Phase” is an intermediate step of a process and that process in Maven terminology is known as “Build Life Cycle”. A life-cycle can have multiple phases in its execution. If we look at the default life-cycle of maven it contains multiple phases in it and each of them will execute sequentially that means next phase in the life-cycle will be executed only when previous phase to it is completed. Below maven phases come under the default build life-cycle,

  1. Validate: validate the project is correct and all necessary information is available.
  2. Compile: compile the source code of the project.
  3. Package: take the compiled code and package it in its distributable format, such as a JAR.
  4. Install: install the package into the local repository, for use as a dependency in other projects locally.
  5. Deploy: done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

When you invoke any phase, all the phases that comes before that phase will be invoked automatically:

mvn compile — it will call all the phases that exists before compile, i.e. validate.

mvn install — it will invoke validate >> compile >> package >> install.

Maven Goals

A goal represents a specific task which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build life-cycle by direct invocation. The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked. For example, consider the command below,

mvn clean dependency:copy-dependencies package

  • The clean and package arguments are ‘build phases’ while the dependency:copy-dependencies is a goal.
  • Here the clean phase will be executed first, followed by the dependency:copy-dependencies goal, and finally package phase will be executed.

Goals are executed in phases which help determine the order goals get executed in. The best understanding of this is to look at the default life-cycle bindings which shows which goals get run in which phases by default. The compile phase goals will always be executed before the test phase goals which will always be executed before the package phase goals and so on.


Maven is organized in plugins, i.e. a plugin execution framework where every task is actually done by plugins. Every piece of functionality in Maven is provided by a plugin. Plugins provide goals and use the metadata found in the POM to perform their task. Examples of plugins are: jar, eclipse, war. Plugins are primarily written in Java, but it also supports writing plug-ins in Beanshell and Ant Scripting. Plugins are generally used to,

Create jar file | Create war file | Compile code files | Unit testing | Create project documentation | Create project reports

Types of Plug-ins,

  • Build plugins: They execute during the build and should be configured in the <build/> element of pom.xml
  • Reporting plugins: They execute during the site generation and they should be configured in the <reporting/> element of the pom.xml

A plugin generally provides a set of goals, which can be executed using the following syntax,

mvn [plugin-name]:[goal-name]

For example, a Java project can be compiled with,

  • Plugin: maven-compiler
  • Goal: compile

By running the following command,

mvn compiler:compile


A plugin written in Java consists of one or more mojos. A mojo is a Java class that implements the org.apache.maven.plugin.Mojo interface. This means that a mojo is the implementation for a goal in a plugin.

APT & XDoc

  • APT is a wiki-like format of documentation that Maven currently understands.
  • XDoc is the format of documentation. It is quite simple, and allows embedding XHTML within a simple layout that is transformed into a uniform site.

Maven simplifies and standardizes the project build process. It handles compilation, distribution, documentation, team collaboration and other tasks seamlessly. It increases re-usability and takes care of most of the build related tasks. Hope this article was useful to clear some of the most common Maven concepts. If yes, don’t forget to share 🙂



Leave a Reply

Your email address will not be published.