Maven multi-module project dependency build order management: use the -am parameter

This tutorial details how to ensure that local module dependencies with non-parent-child relationships are correctly built before the main project in a Maven multi-module project. By explaining `mvn clean install -pl With the -am` command and its core parameter `-am` (also make), we will demonstrate how to use Maven's reactor mechanism to efficiently manage the build sequence of complex dependencies and ensure smooth compilation and packaging of the project.

Introduction: Building challenges of Maven multi-module projects

As a powerful project management tool, Maven's multi-module feature greatly simplifies the management and construction of large projects. By splitting a large project into multiple independent modules, each module can have its own responsibilities and life cycle, thereby improving code reusability and reducing coupling. However, in actual development, the dependency relationship between modules is not always a simple parent-child structure. When a main application module depends on other local, non-parent-child modules, it becomes a common challenge to ensure that these dependent modules are compiled and installed correctly before the main module is built.

Understanding the Problem: Pre-Build Requirements for Local Module Dependencies

Consider a typical scenario: you have a main application module named maven-Hell, which needs to depend on two other independent local modules aaa and ddd when compiling. These modules may be in the same Maven aggregation project (Reactor), but there is no direct parent-child inheritance relationship between them. When you do mvn clean install on the maven-Hell module, you want Maven to intelligently recognize and build aaa and ddd first, and then build maven-Hell. If these dependent modules are not pre-built into the local Maven repository, the maven-Hell build will fail because it cannot find the required dependencies.

Core of the solution: Detailed explanation of mvn -am parameters

In order to solve the above problems, Maven provides a set of powerful command line parameters, the most critical of which is the -am (also make) parameter. Combined with the -pl (projects) parameter, we can precisely control the build order of multi-module projects.

Commonly used command formats are as follows:

 mvn clean install -pl <target-module-id> -am [-P <profile-id>] [-f <path-to-pom>]</path-to-pom></profile-id></target-module-id>

• clean install : This is Maven's standard lifecycle command to clean and install the project into the local Maven repository.
• -pl (or --projects ) : This parameter is used to specify one or more specific modules to build. is usually the artifactId of the module. This parameter is useful if you only want to build a certain submodule in the project, rather than the entire aggregate project.
• -am (or --also-make) : This is the key parameter to solve the core problem. When used with -pl, it tells Maven to build not only the specified module, but also all other modules that this module depends on. Maven will automatically determine the correct build order based on dependencies between modules.
• -P (or --activate-profiles ) : Use this parameter if your project defines specific Maven profiles (profiles) and you need to activate them at build time.
• -f (or --file ) : If you do not execute the command in the root directory of the project, or need to specify a POM file with a non-default name, you can use this parameter to specify the path to pom.xml. When executing in the root directory of a multi-module project, explicit specification is usually not required.

Practical example: building maven-Hell and its local dependencies

Suppose we have a Maven multi-module project with the following structure:

 my-multi-module-project/
├── pom.xml # Parent POM, aggregates all modules ├── aaa/
│ └── pom.xml # module aaa
├── ddd/
│ └── pom.xml # module ddd
└── maven-Hell/
    └── pom.xml # Main application module maven-Hell

In my-multi-module-project/pom.xml, all submodules are aggregated:

 <?xml version="1.0" encoding="UTF-8"?>
<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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelversion>4.0.0</modelversion>

    <groupid>com.example</groupid>
    <artifactid>my-multi-module-project</artifactid>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <modules>
        <module>aaa</module>
        <module>ddd</module>
        <module>maven-Hell</module>
    </modules>

    <properties>
        <project.build.sourceencoding>UTF-8</project.build.sourceencoding>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
        <aaa.version>1.1.1</aaa.version>
        <ddd.version>3.3.3</ddd.version>
    </properties>

    <dependencymanagement>
        <dependencies>
            <dependency>
                <groupid>com.dor.lub</groupid>
                <artifactid>aaa</artifactid>
                <version>${aaa.version}</version>
            </dependency>
            <dependency>
                <groupid>com.dor.dabu</groupid>
                <artifactid>ddd</artifactid>
                <version>${ddd.version}</version>
            </dependency>
        </dependencies>
    </dependencymanagement>

</project>

The dependency on aaa and ddd is declared in maven-Hell/pom.xml:

 <?xml version="1.0" encoding="UTF-8"?>
<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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelversion>4.0.0</modelversion>
    <parent>
        <groupid>com.example</groupid>
        <artifactid>my-multi-module-project</artifactid>
        <version>1.0.0-SNAPSHOT</version>
    </parent>

    <groupid>com.dor.hell</groupid>
    <artifactid>maven-Hell</artifactid>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <dependencies>
        <dependency>
            <groupid>com.dor.lub</groupid>
            <artifactid>aaa</artifactid>
            <version>${aaa.version}</version>
        </dependency>
        <dependency>
            <groupid>com.dor.dabu</groupid>
            <artifactid>ddd</artifactid>
            <version>${ddd.version}</version>
        </dependency>
        <!-- Other dependencies-->
    </dependencies>

</project>

Now, in order to automatically build aaa and ddd before building maven-Hell, we can execute the following command in the root directory of my-multi-module-project:

 cd my-multi-module-project/
mvn clean install -pl maven-Hell -am

After executing this command, Maven's build process will be:

1. Maven recognizes the maven-Hell module.
2. Due to the presence of the -am parameter, Maven will parse the dependencies of maven-Hell and find that it depends on aaa and ddd.
3. Maven will first perform a clean install operation on the aaa and ddd modules in the correct order (if there are dependencies between aaa and ddd, Maven will handle it) and install them into the local Maven repository.
4. Finally, Maven will perform a clean install operation on the maven-Hell module.

In this way, maven-Hell can find the correct versions of aaa and ddd when building, ensuring the smooth compilation and packaging of the entire project.

Things to note and best practices

1. Principle of Reactor : The effectiveness of the mvn -am command depends on Maven's reactor mechanism. All related modules must be part of the same aggregate project (i.e. declared in the tag of the same parent POM), or at least be visible in Maven's build environment. Maven will build a dependency graph of all modules and build them in topological sorting order.
2. Version management : In multi-module projects, it is strongly recommended to use in the parent POM to uniformly manage the dependency versions of all sub-modules. This avoids version conflicts and ensures that all modules use consistent dependency versions.
3. Inter-module dependency declaration : Ensure that each module's pom.xml correctly declares its dependencies on other local modules, including groupId, artifactId and version. This is the basis for Maven to understand dependencies.
4. Applicable scenarios : This method is particularly suitable for complex microservice architectures, in which multiple service modules may depend on each other, but there is no strict parent-child module relationship. With the -am parameter, you can easily build one or more specified services and all their internal dependencies.
5. Build the entire project : If you want to build all modules in the entire multi-module project, just execute mvn clean install in the root directory without the -pl and -am parameters. Maven will automatically build all modules in dependency order. -pl and -am are mainly used for local builds targeting specific modules and their dependencies.

Summarize

The mvn -pl -am command is a powerful tool in Maven multi-module project management. It can effectively solve the build order problem of local module dependencies that are not parent-child relationships. By understanding and skillfully using the -am parameter, developers can manage the construction process of complex projects more flexibly and efficiently, ensuring that dependencies are correctly resolved, thereby improving development efficiency and project stability. Mastering Maven's reactor mechanism and command line parameters is the key to becoming an efficient Maven user.

The above is the detailed content of Maven multi-module project dependency build order management: use the -am parameter. For more information, please follow other related articles on the PHP Chinese website!