Automated build tool: Maven

1. Maven basis

1.1 the Maven installation

The download and installation process of Maven is not covered here. The following are the environment variables that need to be configured after Maven is installed

Configuring environment Variables

(1) Add variable M2_HOME to Maven installation directory, for example: D: Program Files (x86)\ maven-3.6.1 (2) add M2_HOME to system variable PATH, that is, add %M2_HOME%/bin to PATH;Copy the code

1.2 the Maven configuration

(1) Configure the local repository

Modify the localRepository tag in settings. XML to specify the localRepository, as shown below:

<localRepository>D: \ \ Program Files \ Maven (x86) \ Maven - 3.6.1 \ repository</localRepository>
Copy the code

(2) Configure the mirror

Sometimes the central repository of Maven is slow to download files. We can configure a domestic Maven repository image to download files very quickly. The following is the configuration of ali Cloud mirror:

<mirrors>
    <mirror>
        <id>aliyunmvn</id>
        <name>aliyunmvn</name>
        <indexOf>public</indexOf>
        <url>https://maven.aliyun.com/repository/public</url>
    </mirror>
</mirrors>
Copy the code

Note: Some students set the value of indexOf tag to * when configuring the image of Ali Cloud, * means matching any remote warehouse, which may cause the remote warehouse specified by the user in the pom. XML file to be invalid. To avoid this, set indexOf to a specific repository name.

Maven repository for Alicloud:

1.3 Maven Project directory Structure

When creating projects using Maven, the default project directory structure looks like this:

|---src
|---|---main
|---|---|---java
|---|---|---resources
|---|---test
|---|---|---java
|---|---|---resources
|---pom.xml
Copy the code

SRC /main/ Java: The main program class file
SRC /main/resources: resource files that store the main program, such as configuration files and static resource files
SRC /test/ Java: the class file that stores the test program
SRC /test/resources: resource files that store test programs, such as configuration files and static resource files
Pom. XML: POM file

1.4 Resource Retrieval

When you introduce rely on but I don’t know that rely on coordinates, you can visit https://mvnrepository.com, and then by keyword can query the information you need.

2. Maven’s life cycle, commands, and plug-ins

2.1 Life Cycle

Maven’s life cycle is essentially an abstraction of the project construction process. Maven defines three life cycles: Clean, Default, and Site. Each lifecycle contains phases, such as cleaning, compiling, testing, packaging, deploying, and so on. , these phases can be done through Maven-related commands, but are actually implemented through the corresponding Maven plug-in.

Tips: The most common life cycle we use during project development is default, which is at the heart of Maven's life cycle.Copy the code

2.2 Maven Basic Commands

MVN clean: Clears the previously compiled directory, that is, the target directory, but the dependency packages that have been installed in the local repository will not be deleted

MVN compile: Compile the main program, which generates a target directory. The compiled bytecode files are stored in the target /classes directory

MVN test-compile: the test program is compiled. A target directory is generated, and the compiled bytecode files are stored in the test-classes directory

MVN Test: Tests are performed and the results are placed in the Target/Surefire-Reports directory

MVN package: package the main program. Executing this command compiles and then packages the package. The package result is stored in the target directory by default

MVN install: installs the main program. This command compiles the package and then installs it. The purpose of install is to store the package in a local repository for other projects to use

2.3 Common Maven plug-ins

Maven is a plug-in framework, and each phase of Maven’s life cycle is accomplished by a different plug-in. For example, at compile time, the Maven-Compiler-plugin plugin is required to specify the JDK version to be used at compile time. During the packaging phase, the maven-jar-plugin or maven-war-plugin is required to complete the packaging of the project, etc…..

Because of this, we need to learn and summarize some commonly used Maven plug-ins so that we can use Maven properly in the future and improve development efficiency.

(1) the maven – compiler – plugins plugin

Maven-complier-plugin is used to specify the JDK version and encoding format to be used during compilation. If not explicitly specified, the maven-complier-plugin plugin’s default JDK will be used at compile time, which may cause the project to fail to compile. For example, the code uses a new Java 8 feature, but uses JDK 6 at compile time, thus causing the compile to fail.

Example:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.6.2</version>
            <configuration>
                <! -- Set source JDK version -->
                <source>1.8</source>
                <! -- Set the JDK version used for compilation -->
                <target>1.8</target>
                <! -- Set character encoding -->
                <encoding>UTF-8</encoding>
            </configuration>
        </plugin>
    </plugins>
</build>
Copy the code

(2) the maven – jar – plugin plug-in

Maven-jar-plugin is maven’s default package plug-in that separates executable JARS from dependencies. The packaged JARS are stored in the target directory, the dependencies in the target/lib directory, and the executable jars are at the same level as the lib directory.

After maven-jar-plugin is packaged, a manifest.mf file will be generated in the mate-INF directory of the jar package. This file mainly records the classpath read by the current JAR package and the location of the dependent package.

Example:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <version>3.1.0</version>
            <configuration>
                <! File -- -- -- >
                <archive>
                    <! -- Configuration list -->
                    <manifest>
                        <! -- Specify entry program -->
                        <mainClass>com.example.Application</mainClass>
                        <! Add the classpath of the dependent package to the classpath of the current JAR
                        <addClasspath>true</addClasspath>
                        <! -- Directory for storing dependent packages -->
                        <classpathPrefix>lib/</classpathPrefix>
                    </manifest>
                    <! Append the classpath read by the current jar -->
                    <manifestEntries>. /</manifestEntries>
                </archive>
                <! -- Exclude files that don't need to be packaged together -->
                <excludes>
                    <exclude>omit</exclude>
                </excludes>
            </configuration>
        </plugin>
    </plugins>
</build>
Copy the code

(3) the maven – resource – plugins plugin

By default, the maven-resource-plugin only reads all files in SRC /main/resources and copies all files in SRC /main/resources to target/classes at compile time. However, if your resource files are in a different directory, you need to configure the Maven-resource-plugin to read the specified resource files.

Example:

<build>
    <plugins>
    	<plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-resources-plugin</artifactId>
            <version>2.6</version>
        </plugin>
    </plugins>
    
    <! -- Resource Allocation -->
    <resources>
        <! Properties,.xml,.yml,.yaml files in SRC /main/resources directory
        <resource>
            <directory>src/main/resources/</directory>
            <includes>
                <include>**/*.properties</include>
                <include>**/*.xml</include>
                <include>**/*.yml</include>
                <include>**/*.yaml</include>
            </includes>
        </resource>
        <! SRC /main/resources directory with.xml -->
        <resource>
        	<directory>src/main/java/</directory>
            <includes>
                <include>**/*.xml</include>
            </includes>
        </resource>
    </resources>
</build>
Copy the code

Learn more about Plugins in the Maven Plugins section.

3. Dependency management

3.1 Scope of dependency

When a dependency is introduced into the POM.xml file, the scope of the dependency is specified by the

tag. The scope of the dependency is used to control the phase in which the dependency package takes effect. The optional values of the

tag are as follows:

Compile: The default dependency scope. If compile is used, the dependency packages are valid for both the compile and run phases of the main program and the test program
Test: Test dependency range. If test is used, the dependency package does not take effect during compilation and execution of the main program, but during compilation and execution of the test program. For example, when junit dependencies are introduced, the dependency scope is test
Provided: Dependency scope. If provided is used, dependency packages take effect at compile time of the main program and test program, but not at run time. For example, when the Javax. servlet-api dependency is introduced, the scope of the dependency is provided because the Tomcat container provides the Javax. servlet-api dependency at run time
Runtime: runtime dependency scope. If runtime is used, dependency packages do not take effect at compile time of the main program and test program, but only at runtime
Import: Import dependency scope. This dependency scope can only be used in<dependencyManagement>Only valid if used under the label
Provided: provided provided: provided provided: provided provided

3.2 Transitivity of dependencies

Suppose there are three items A, B and C, A depends on B, B depends on C, then A depends on C; Maven dependency transitivity is described as follows:

A->B; B->C => A->C
Copy the code

Effects of transitivity of dependency on scope of dependency:

	compile	test	provided	runtime
compile	compile	–	–	runtime
test	test	–	–	test
provided	provided	–	provided	provided
runtime	runtime	–	–	runtime

In the above table, the dependence range of the leftmost column is the dependence range of the first direct dependence, and the dependence range of the top row is the dependence range of the second direct dependence. The rules are summarized as follows:

If the dependency range of the second direct dependency iscompile, the scope of the passed dependency is the same as the first direct dependency
If the dependency range of the second direct dependency istest, the dependency is not transitive
If the dependency range of the second direct dependency isprovided, then only the dependence scope of the first direct dependence is alsoprovidedWhen, the dependency is passed
If the dependency range of the second direct dependency isruntime, the scope of the passed dependency is the same as that of the first direct dependency, except that the scope of the first direct dependency iscompileoutside

Reference documentation

The Maven website
Maven dependency scope and Classpath and dependency transitivity

1. Maven basis

1.1 the Maven installation

1.2 the Maven configuration

1.3 Maven Project directory Structure

1.4 Resource Retrieval

2. Maven’s life cycle, commands, and plug-ins

2.1 Life Cycle

2.2 Maven Basic Commands

2.3 Common Maven plug-ins

3. Dependency management

3.1 Scope of dependency

3.2 Transitivity of dependencies

Reference documentation

Related Posts

How exactly does Demeter’s principle work in code

Chapter 3 Using Multidimensional Storage (Global Variables) (2)

First look at the Spring Cloud family – Security features