maven.tar.gz

Maven is the de-facto build tool of choice for Java projects and has wide adoption at the enterprise level.

In this course, you will learn the fundamentals of Maven so that you can start to inject build automation into your own projects. You’ll start by exploring the basics such as plugins, goals, coordinates, and lifecycles.

In the latter half, you will dive into more advanced concepts such as dependencies, inheritance, aggregation, and build profiles. 

By the end of this course, you will have just the right amount of knowledge for you to quickly become productive when working with Maven.

Build Java Projects with Maven

We'll examine the convention followed for declaring versions of projects in this lesson and also the SNAPSHOT version.

## Version

The version for a project should follow the below pattern:

<b>&lt;majorVersion>.&lt;minorVersion>.&lt;incrementalVersion>-&lt;qualifier></b>

For instance, the project version **5.4.12** implies the major version is 5, minor is 4, incremental is 12, and that there is no qualifier. Similarly, the project version **2.5.1-alpha** implies the major version is 2, minor 5, incremental 1, and that the qualifier is alpha. Finally, a project version **4** implies the major version is 4 and the rest are not defined. Following this format for defining project versions is helpful when defining project dependencies. We can define project dependencies as a range instead of a specific version. Maven will be able to determine the versions of a project that fall into a range if the above pattern of naming the project versions is followed. A range can be specified using the following:

1. **(, )** exclusive quantifiers
2. **[, ]** inclusive quantifiers 
 
For instance, if the version is specified as below:

```xml
<version>[3.8, 4.0)</version>
```

It implies that the dependency with a version of 3.8 or higher but less than 4.0 should be used. The lower boundary is inclusive, but the upper boundary is exclusive.


## SNAPSHOT version
As a developer you'll often come across artifact versions labelled as SNAPSHOT. A snapshot version signifies that the project is under active development and is treated slightly differently when deployed by Maven in a repository. The SNAPSHOT value refers to the _latest_ code along a development branch and isn't considered stable or unchanging. Consider a large organization that has several teams working on different parts of a product. If team A depends on a feature of team B's actively developed artifact, then it will take a dependency on the SNAPSHOT version of the artifact. Team B will work on the feature and make daily releases as SNAPSHOT versions. Team B can't make a regular release of the artifact as it is still being worked on, and team A must have access to the new code that is being created by members of team B. The solution for team B is to release code as a SNAPSHOT version to the organization's internal repository. Maven always fetches the latest SNAPSHOT version from the remote repository for a SNAPSHOT dependency. This is in contrast to regular versions, whereby Maven looks up the dependency in the local repository; if found, an attempt to fetch the dependency from the remote repository is not made.

When uploading/deploying an artifact to a repository, if Maven encounters a version ending in "-SNAPSHOT", it substitutes the token with a timestamp. The repository manager and client tools manage the translation from the snapshot version to the timestamped version. As a user, if you want to add a SNAPSHOT dependency, you'll put in the version as "*-SNAPSHOT" and always get the latest version of the dependency. Here's an [example](https://repository.apache.org/content/groups/snapshots/commons-io/commons-io/2.8.0-SNAPSHOT/) from the internet. 


![](/api/collection/5352985413550080/5706364891430912/page/5887526083493888/image/5900705257750528)

Notice that the version is set to "2.8.0-SNAPSHOT" and consists of jars with timestamps in their name. The idea is that you can continuously push the latest changes as a SNAPSHOT version and anyone depending on it gets the latest changes every time they build their project. Then, after a few iterations, when the code is stable enough, the latest SNAPSHOT version is permanently released as a regular version. In essence, the difference between a regular version and a SNAPSHOT version is that the SNAPSHOT version may get updates but the regular one will not. This implies, for instance, that downloading **1.0-SNAPSHOT** of an artifact today might give a different file than downloading it yesterday or tomorrow. Finally, be cognizant that during the release process, a version of **x.y-SNAPSHOT** changes to **x.y**. The release process also increments the development version to **x.(y+1)-SNAPSHOT**. The snapshot precedes the actual release, it does not come after it. For instance, **version 1.0-SNAPSHOT** is released as **version 1.0**, and the new development version is **version 1.1-SNAPSHOT**.

We'll examine the convention followed for declaring versions of projects in this lesson and also the SNAPSHOT version.

# Version

The version for a project should follow the below pattern:

<b>&lt;majorVersion>.&lt;minorVersion>.&lt;incrementalVersion>-&lt;qualifier></b>

For instance, the project version **5.4.12** implies the major version is 5, minor is 4, incremental is 12, and that there is no qualifier. Similarly, the project version **2.5.1-alpha** implies the major version is 2, minor 5, incremental 1, and that the qualifier is alpha. Finally, a project version **4** implies the major version is 4 and the rest are not defined. Following this format for defining project versions is helpful when defining project dependencies. We can define project dependencies as a range instead of a specific version. Maven will be able to determine the versions of a project that fall into a range if the above pattern of naming the project versions is followed. A range can be specified using the following:

1. **(, )** exclusive quantifiers
2. **[, ]** inclusive quantifiers 
 
For instance, if the version is specified as below:

```xml
<version>[3.8, 4.0)</version>
```

It implies that the dependency with a version of 3.8 or higher but less than 4.0 should be used. The lower boundary is inclusive, but the upper boundary is exclusive.


# SNAPSHOT version
As a developer you'll often come across artifact versions labelled as SNAPSHOT. A snapshot version signifies that the project is under active development and is treated slightly differently when deployed by Maven in a repository. The SNAPSHOT value refers to the _latest_ code along a development branch and isn't considered stable or unchanging. Consider a large organization that has several teams working on different parts of a product. If team A depends on a feature of team B's actively developed artifact, then it will take a dependency on the SNAPSHOT version of the artifact. Team B will work on the feature and make daily releases as SNAPSHOT versions. Team B can't make a regular release of the artifact as it is still being worked on, and team A must have access to the new code that is being created by members of team B. The solution for team B is to release code as a SNAPSHOT version to the organization's internal repository. Maven always fetches the latest SNAPSHOT version from the remote repository for a SNAPSHOT dependency. This is in contrast to regular versions, whereby Maven looks up the dependency in the local repository; if found, an attempt to fetch the dependency from the remote repository is not made.

When uploading/deploying an artifact to a repository, if Maven encounters a version ending in "-SNAPSHOT", it substitutes the token with a timestamp. The repository manager and client tools manage the translation from the snapshot version to the timestamped version. As a user, if you want to add a SNAPSHOT dependency, you'll put in the version as "*-SNAPSHOT" and always get the latest version of the dependency. Here's an [example](https://repository.apache.org/content/groups/snapshots/commons-io/commons-io/2.8.0-SNAPSHOT/) from the internet. 


![](/api/collection/5352985413550080/5706364891430912/page/5887526083493888/image/5900705257750528)

Notice that the version is set to "2.8.0-SNAPSHOT" and consists of jars with timestamps in their name. The idea is that you can continuously push the latest changes as a SNAPSHOT version and anyone depending on it gets the latest changes every time they build their project. Then, after a few iterations, when the code is stable enough, the latest SNAPSHOT version is permanently released as a regular version. In essence, the difference between a regular version and a SNAPSHOT version is that the SNAPSHOT version may get updates but the regular one will not. This implies, for instance, that downloading **1.0-SNAPSHOT** of an artifact today might give a different file than downloading it yesterday or tomorrow. Finally, be cognizant that during the release process, a version of **x.y-SNAPSHOT** changes to **x.y**. The release process also increments the development version to **x.(y+1)-SNAPSHOT**. The snapshot precedes the actual release, it does not come after it. For instance, **version 1.0-SNAPSHOT** is released as **version 1.0**, and the new development version is **version 1.1-SNAPSHOT**.

This lesson explains the naming conventions for project versions in Maven. It also explains the special role of the SNAPSHOT version.

Theory

Versions

Version