Maven is a tool for managing and building Java projects.

It simplifies dependency management (jar files) to avoid version conflicts, provides a standard project structure, and offers a cross-platform automated build process.

Installation

Download it from the official website and unzip it. Configure the local repository by modifying the <localRepository> tag in conf/setting.xml to a specific directory.

1
2

<!-- Example local repo at D:\develop\maven_repo -->
<localRepository>D:\develop\maven_repo</localRepository>

To configure the Aliyun mirror, modify the <mirror> tag in conf/setting.xml by adding a child tag:

1
2
3
4
5
6

<mirror>
    <id>alimaven</id>
    <name>aliyun maven</name>
    <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
    <mirrorOf>central</mirrorOf>
</mirror>

Configure environment variables: set MAVEN_HOME to the Maven installation directory and add its bin folder to the PATH variable.

Verify the installation: run mvn -v in the command line to check the output.

Dependency Configuration

Dependencies are the jar files required to run the project. A single project can include multiple dependencies.

Configuration steps:

1. Add the <dependencies> tag in pom.xml.
2. Use the <dependency> tag inside <dependencies> to import coordinates.
3. Define the groupId, artifactId, and version.
4. Refresh the configuration to import the new dependencies.

1
2
3
4
5
6
7
8

<!-- Example: Importing logback -->
<dependencies>
    <dependency>
        <groupId>ch.qos.logback</groupId>
        <artifactId>logback-classic</artifactId>
        <version>1.2.3</version>
    </dependency>
</dependencies>

You can find dependency coordinates at https://mvnrepository.com/ .

Dependency Transitivity

Dependencies are transitive.

• Direct Dependency: A dependency explicitly defined in the current project.
• Indirect Dependency: When a dependency depends on other resources, the current project implicitly depends on those resources.

When you add a dependency that relies on other packages, those packages are added automatically.

If you don’t need a specific sub-dependency, you can exclude it (this breaks the dependency link; no version is required for excluded resources).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

<!-- Example: Excluding junit from a project -->
<dependency>
    <groupId>com.yexca</groupId>
    <artifactId>maven-project</artifactId>
    <version>1.0-SNAPSHOT</version>
    <exclusions>
        <exclusion>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Dependency Scope

By default, jar files are available everywhere. You can use <scope>...</scope> to limit their scope:

• Main program scope (inside the main folder).
• Test program scope (inside the test folder).
• Packaging and execution (during the package phase).

1
2
3
4
5
6

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.10</version>
    <scope>test</scope>
</dependency>

Lifecycle

The Maven lifecycle abstracts and unifies the build process for all Maven projects.

There are 3 independent lifecycles:

• clean: Cleanup tasks.
• default: Core tasks like compile, test, package, install, and deploy.
• site: Generating reports and publishing sites.

Each lifecycle consists of several phases. Phases are sequential; later phases depend on the completion of earlier ones.

clean

• pre-clean
• clean: Removes files generated by previous builds (the target folder).
• post-clean

default

• validate
• initialize
• generate-sources
• process-sources
• generate-resources
• process-resources
• compile: Compiles the source code.
• process-classes
• generate-test-sources
• process-test-sources
• generate-test-resources
• process-test-resources
• test-compile
• process-test-classes
• test: Runs tests using a unit testing framework (e.g., JUnit).
• prepare-package
• package: Packages compiled code (e.g., jar, war).
• verify
• install: Installs the project into the local repository.
• deploy

site

• pre-site
• site
• post-site
• site-deploy

Within the same lifecycle, running a later phase automatically triggers all preceding phases.

Multi-module Design

Multi-module design allows splitting a large project into several independent modules during the design phase. If one module needs functionality from another, it can simply depend on that module.

Common entities or utility classes can be placed in separate modules to be shared. This improves project management, maintenance, scalability, and resource sharing.

Inheritance

Dependencies like Lombok might be used in every module. Instead of declaring it in every module, you can use inheritance.

Inheritance Relationship

Create a parent project and move shared dependencies to its configuration. Child projects inheriting from the parent will automatically inherit these dependencies, eliminating redundant configuration.

Inheritance describes the relationship between two projects, similar to inheritance in Java. It simplifies dependency management and ensures consistency.

1
2
3
4
5
6
7

<!-- Specifying the parent project -->
<parent>
    <groupId>...</groupId>
    <artifactId>...</artifactId>
    <version>...</version>
    <relativePath>....</relativePath>
</parent>

In JavaWeb development, the parent project can inherit from spring-boot-starter-parent, while other modules inherit from that parent project.

Usually, child projects are located in subdirectories of the parent project.

Example:

1. Parent project packaging type is pom:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.5</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

<groupId>net.yexca</groupId>
<artifactId>tlias-parent</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>

Maven Packaging Types:

• jar: Standard module packaging. SpringBoot projects usually use this (run via embedded Tomcat).
• war: Standard web program packaging for external Tomcat servers.
• pom: Parent or aggregation project. Contains no code, used only for dependency management.

2. Child project specifies the parent:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

<parent>
    <groupId>net.yexca</groupId>
    <artifactId>tlias-parent</artifactId>
    <version>1.0-SNAPSHOT</version>
    <!-- Relative path to parent pom (defaults to local/remote repo if not specified) -->
    <relativePath>../tlias-parent/pom.xml</relativePath>
</parent>

<!-- <groupId> can be omitted as it is inherited from the parent -->
<artifactId>tlias-utils</artifactId>
<version>1.0-SNAPSHOT</version>

3. Parent project configures shared dependencies:

1
2
3
4
5
6
7

<dependencies>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.24</version>
    </dependency>
</dependencies>

Version Management

If only some modules need a dependency, you can manage the version in the parent project to ensure consistency.

Use the <dependencyManagement> tag for version locking.

Parent Project:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

<!-- Unified dependency version management -->
<dependencyManagement>
    <dependencies>
        <!-- JWT Token -->
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
            <version>0.9.1</version>
        </dependency>
    </dependencies>
</dependencyManagement>

Child Project:

1
2
3
4
5
6
7
8

<dependencies>
    <!-- JWT Token -->
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt</artifactId>
        <!-- No version needed as it's defined in the parent -->
    </dependency>
</dependencies>

The <dependencyManagement> in the parent only manages the version; it does not actually import the dependency into children. Children must explicitly include the dependency (without a version) to use it.

In contrast, <dependencies> imports the dependency into all child projects automatically.

Attribute Configuration (Properties)

You can use custom properties to centralize version management in the parent project.

Define attributes:

1
2
3

<properties>
    <lombok.version>1.18.24</lombok.version>
</properties>

Reference attributes:

1
2
3
4
5

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>${lombok.version}</version>
</dependency>

Centralized management in the parent project:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

<properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>

    <lombok.version>1.18.24</lombok.version>
    <jjwt.version>0.9.1</jjwt.version>
    <aliyun.oss.version>3.15.1</aliyun.oss.version>
    <jaxb.version>2.3.1</jaxb.version>
    <activation.version>1.1.1</activation.version>
    <jaxb.runtime.version>2.3.3</jaxb.runtime.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>${lombok.version}</version>
    </dependency>
</dependencies>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
            <version>${jjwt.version}</version>
        </dependency>
        <dependency>
            <groupId>com.aliyun.oss</groupId>
            <artifactId>aliyun-sdk-oss</artifactId>
            <version>${aliyun.oss.version}</version>
        </dependency>
        <!-- ... other dependencies ... -->
    </dependencies>
</dependencyManagement>

To update a version, you only need to change the property value in the parent project.

Aggregation

If one module depends on another, you usually have to install the dependency module to the local repo before packaging the main module. This gets tedious with many modules.

Maven aggregation allows for one-click project builds (clean, compile, test, package, install, etc.).

• Aggregation: Organizing multiple modules into a single unit for simultaneous building.
• Aggregation Project: An “empty” project containing only a pom.xml (usually the same as the parent project in inheritance).
• Purpose: Fast project building without manually following dependency order.

Define sub-modules in the aggregation project using the <modules> tag.

1
2
3
4
5
6
7

<!-- Aggregating other modules -->
<modules>
    <!-- Project paths -->
    <module>../tlias-pojo</module>
    <module>../tlias-utils</module>
    <module>../tlias-web-management</module>
</modules>

Running compile, package, or install on the aggregation project will automatically sync those operations to all sub-modules.

Private Repositories

A private repository (Nexus, Artifactory) is a remote repository hosted on a local network. It acts as a proxy for the central repository and facilitates resource sharing and synchronization within a team.

When a project needs a dependency, Maven checks the local repo. If missing, it checks the private repo. If the private repo doesn’t have it, it downloads it from the central repository, caches it, and serves it to the local repo.

Companies usually provide a private repository, so you won’t need to configure your own.

Private Repo Types and Project Versions

Private Repo Categories:

• RELEASE: For finished RELEASE versions of internal code.
• SNAPSHOT: For internal development SNAPSHOT versions.
• Central: Proxied dependencies downloaded from the Maven Central Repository.

Project Versioning:

• RELEASE: Stable, finished versions for deployment, stored in the RELEASE repo.
• SNAPSHOT: Unstable, work-in-progress versions, stored in the SNAPSHOT repo.

Configuration

Set the private repo username and password in conf/settings.xml under the <servers> tag:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

<servers>
<server>
    <id>maven-releases</id>
    <username>admin</username>
    <password>admin</password>
</server>
    
<server>
    <id>maven-snapshots</id>
    <username>admin</username>
    <password>admin</password>
</server>
</servers>

Configure the download address in settings.xml using the <mirrors> and <profiles> tags:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

<mirrors>
<mirror>
    <id>maven-public</id>
    <mirrorOf>*</mirrorOf>
    <url>http://127.0.0.1:8081/repository/maven-public/</url>
</mirror>
</mirrors>

<profiles>
<profile>
    <id>allow-snapshots</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
    <repositories>
        <repository>
            <id>maven-public</id>
            <url>http://127.0.0.1:8081/repository/maven-public/</url>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </repository>
    </repositories>
</profile>
</profiles>

Configure the upload target in the parent project’s pom.xml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

<distributionManagement>
    <!-- Release release address -->
    <repository>
        <id>maven-releases</id>
        <url>http://127.0.0.1:8081/repository/maven-releases/</url>
    </repository>

    <!-- Snapshot release address -->
    <snapshotRepository>
        <id>maven-snapshots</id>
        <url>http://127.0.0.1:8081/repository/maven-snapshots/</url>
    </snapshotRepository>
</distributionManagement>

Once configured, execute the deploy lifecycle phase on the parent project to publish it to the private repository.