Course – LS – All

Get started with Spring and Spring Boot, through the Learn Spring course:

>> CHECK OUT THE COURSE

1. Overview

Manually building a complex project is quite cumbersome. There are much easier ways to do this using build tools.  As we know, one of the main build tools for Java projects is Maven. Maven helps standardize the build and deployment of applications.

In this tutorial, we’ll discuss what a Maven artifact is and what its key elements are. We’ll also look at Maven coordinates, dependency management, and finally, Maven repositories.

2. What Is Maven?

We can use Maven to build and manage any Java-based project. It provides many functionalities such as:

  • building and compiling
  • documentation and report
  • dependency management
  • source management
  • project update
  • deployment

Each Maven project has its own POM file. We can configure Maven to build either one project or multiple projects.

A multi-project typically defines a POM file in the root directory and lists the individual projects in a modules section. In short, a Maven build produces one or more artifacts.

3. What Is a Maven Artifact?

An artifact is an element that a project can either use or produce. In Maven terminology, an artifact is an output generated after a Maven project build. It can be, for example, a jar, war, or any other executable file.

Also, Maven artifacts include five key elements, groupId, artifactId, version, packaging, and classifier. Those are the elements we use to identify the artifact and are known as Maven coordinates.

4. Maven Coordinates

Maven coordinate is a combination of the values for the groupId, artifactId, and version for a given artifact. Furthermore, Maven uses coordinates to find any component matching the values for groupId, artifactId, and version.

Among the coordinate elements, we must define the groupId, artifactId, and version. The packaging element is optional, and we can’t directly define the classifier.

For instance, the pom.xml configuration file below shows an example of Maven coordinates:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.baeldung</groupId>
    <artifactId>org.baeldung.java</artifactId>
    <packaging>jar</packaging>
    <version>1.0.0-SNAPSHOT</version>
    <name>org.baeldung.java</name>
    <url>http://maven.apache.org</url>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.1.2</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

Let’s look in detail at each of the Maven coordinates.

4.1. The groupId Element

The groupId element is the identifier of the group at the origin of the project. This key makes it easier and quicker to organize and find the project.

Also, a groupId follows the same naming rules as Java packages, and we generally choose as groupId the name of the top package of the project.

For instance, a groupId of org.apache.commons corresponds to ${repository_home}/org/apache/commons.

4.2. The artifactId Element

The artifactId element is the identifier of the project within the group. It is used by default to construct the artifact’s final name. Therefore, this name has some specifications as it should ideally be small in length. The best practice for naming an artifactId is to use the actual project name as a prefix. The advantage of this is that it makes it easier to find the artifacts.

Like the groupId, the artifactId manifests itself as a sub-directory under the directory tree that represents the groupId.

For example, an artifactId of commons-lang3 under a groupId of org.apache.commons, would determine that the artifact is under : ${repository_home}/org/apache/commons/commons-lang3/.

4.3. The version Element

The version is used as part of an artifact’s identifier. It defines the current version of the Maven project. We should note that Maven defines a set of version specifications, as well as the concept of releases and snapshots, that we will cover later.

A version is represented as a subdirectory in the directory tree, which is formed by the groupId and the artifactId.

For instance, a version of 3.1.1 for an artifactId commons-lang3 under the groupId of org.apache.commons would determine that the artifact is located under: ${repository_home}/org/apache/commons/commons-lang3/3.1.1/.

4.4. The packaging Element

This element is used to specify the type of artifact generated by the project. The packaging can be anything that describes any binary software format, including ZIP, EAR, WAR, SWC, NAR, SWF, SAR.

Also, the packaging defines the different goals to execute during the project’s default lifecycle. For instance, the package phase executes the jar:jar goal for a jar-type artifact and the war:war goal for a war-type artifact.

4.5. The classifier Element

We usually use a classifier for technical reasons when delivering the same code but as several separate artifacts.

For example, if we want to build two artifacts of a JAR with different Java compilers, we can do it easily using the classifier as it allows the production of two different artifacts with the same combination for groupId:artifactId:version.

Also, we can use classifiers when packaging source code, an artifact’s JavaDoc, or assembling binaries.

For our above example of commons-lang3, the artifact to look for is: commons-lang3-3.10-javadoc.jar or commons-lang3-3.10-sources.jar, under ${repository_home}/org/apache/commons/commons-lang3/3.1.0/.

5. Release vs. Snapshot Artifacts

Now, let’s see the differences between a snapshot artifact and a release artifact.

5.1. Release Artifacts

A release artifact indicates that the version is stable and can be used outside development processes like integration tests, customer qualification, pre-production, etc.

Also, a release artifact is unique. Running the mvn deploy command will deploy our project to the repository. But, subsequent execution of the same command on the same project with the same version will result in a failure.

5.2. Snapshot Artifacts

A snapshot artifact indicates that the project is under development. When we install or publish a component, Maven checks the version attribute. If it contains the string “SNAPSHOT”, Maven converts this key into a date and time value in UTC (Coordinated Universal Time) format.

For example, if our project is in version 1.0-SNAPSHOT and we deploy its artifacts on a Maven repository, Maven converts this version to “1.0-202202019-230800”, assuming we deploy on February 19, 2022, at 23:08 UTC.

In other words, when we deploy a snapshot, we are not delivering a software component, but we only deliver a snapshot of it.

6. Dependency Management

Dependency management is essential in the Maven world. For instance, when a project depends on other classes in its operating process (compilation, execution), it becomes necessary to identify and import these dependencies from the remote repositories to the local repository. Therefore, the project will have dependencies on these libraries, which will ultimately be added to the classpath of the project.

Furthermore, Maven’s dependency management is based on several concepts:

  • repositories: essential to store artifacts
  • scope: allows us to specify in which context we use a dependency
  • transitivity: allows us to manage the dependencies of dependencies
  • inheritance: POMs inheriting from the parent can set their dependency by providing only the dependency’s groupId and artifactId without the version attribute. Maven gets the appropriate version from the parent POM file.

With Maven, dependency management is done through the pom.xml. For instance, a dependency declaration in the Maven projects looks like this:

<dependencies>
    <dependency>
        <groupId>org.apache.maven</groupId>
        <artifactId>maven-plugin-api</artifactId>
        <version>3.8.4</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-web</artifactId>
        <version>5.3.15</version>
    </dependency>
</dependencies>

7. Maven Repository

Maven uses a repository to store elements like dependencies and plugins required to build projects. This makes it possible to centralize these elements, which are generally used in several projects.

As we mentioned earlier, repositories store artifacts using a set of coordinates: groupId, artifactId, version, and packaging. Furthermore, Maven uses a particular directory structure to organize the contents of a repository and allow it to find the required elements: ${repository_home}/groupId/artifactId/version.

For instance, let’s consider this POM configuration.

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.baeldung</groupId>
    <artifactId>myApp</artifactId>
    <version>1.0.0</version>
</project>

With the above configuration, our project will be stored in a repository in the ${repository_home}/com/baeldung/myApp/1.0.0/ path.

8. Conclusion

In this article, we discussed the concept of Maven artifacts and their coordinates system. Also, we learned related concepts such as dependencies and repositories.

Course – LS – All

Get started with Spring and Spring Boot, through the Learn Spring course:

>> CHECK OUT THE COURSE
res – Maven (eBook) (cat=Maven)
Comments are closed on this article!