MAVEN’s dependency management && life cycle with plugins | August more challenges

preface

After introducing the basic concepts and installation of MAVEN, let’s take a look at the dependency management, lifecycle and plug-ins of MAVEN.

Dependency management

Depend on the configuration

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>2.5.3</version>
    </dependency>
</dependencies>
Copy the code

Depend on the transfer

Dependencies are transitive

• Direct dependency: Passed in the current project<dependency>Directly introduce established dependencies
• Indirect dependencies: Introduced by the current project<dependency>Is dependent on other resources, which is equivalent to indirect dependencies for the current project

Dependency passing conflict problem

• Path priority: The deeper the resource layer, the lower the priority
• Declaration priority: When resources are dependent on the same hierarchy, the first configuration order overrides the second configuration order
• Special priority: different versions of the same resource are configured at the same level, and the later version overrides the previous one

Let’s take this picture a step further.

As shown in the figure, when our project relies on A1.1 at level 1 and then has the same dependencies in subsequent dependencies, even if the version of A1.2 is higher, the current project will use the A1.1 package following the pathfirst principle. Level 2 find two versions of indirect dependence on the B, follow the principle of statement rely on, will eventually adopt B1.1 version, and so on, so there was A special case, C using C1.2 when we accidentally was introduced to the same level directly dependent on the two versions of A, will cover the front behind, so this situation will use A1.2 version.

Optional dependence

External hidden dependency

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>2.5.3</version>
    <optional>true</optional>
</dependency>
Copy the code

true
true
true
true
true
true
true Then the project indirect dependencies will no longer have B1.1 dependencies

Eliminate dependence on

Actively disconnect dependent resources

<dependency>
   <groupId>com.baomidou</groupId>
   <artifactId>mybatis-plus-boot-starter</artifactId>
   <version>3.3.1</version>
   <exclusions>
      <exclusion>
         <groupId>com.baomidou</groupId>
         <artifactId>mybatis-plus-generator</artifactId>
      </exclusion>
   </exclusions>
</dependency>
Copy the code

If the imported dependencies have indirect dependencies that we do not need, run < Exclusions >
to remove them.
has the same effect, but one is indirect dependency, the current project actively removed, one is indirect dependency directly hidden, with no bring over. That’s the essential difference.

Depend on the range

We can use the

tag to implement the scope of the dependency

<dependency>
    <groupId>org.apache.httpcomponents</groupId>
    <artifactId>httpcore</artifactId>
    <version>4.4.13</version>
    <scope>compile</scope>
</dependency>
Copy the code

The scope of action is mainly divided into:

• Main program scope valid
• Test range valid
• Whether to participate in packaging

Refer to the following table

Transitivity of dependency scope (understand)

When a resource with a dependent scope is passed, the scope is affected

• The horizontal represents direct dependence
• The vertical ones represent indirect dependence

Life cycle and plug-ins

Project build lifecycle

The lifecycle describes how many events occur during a build

It can be roughly divided into the following three stages

• Clean: Clean work
• Default: core work, such as compilation, testing, packaging, deployment, etc
• Site: Generate reports, publish sites, etc

Note: Lifecycle execution is sequential, which means that when we execute install, we will run clean,test,package, and install from top to bottom. One more thing to point out here is that this is just a list of the main steps, and there are a lot of details. You can consult relevant information if you are interested.

The plug-in

• Plug-ins are bound to phases within the lifecycle, and the corresponding plug-in functions are executed when the execution reaches the corresponding lifecycle
• The default is a plug-in with each lifecycle, as shown below
• We can also add more plugins to our own needs

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.8.1</version>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
                <encoding>UTF-8</encoding>
            </configuration>
        </plugin>
    </plugins>
</build>
Copy the code

conclusion

At this point, we were able to solve almost all of the dependency problems we encountered in our projects, and when we encountered conflicts, we were able to quickly identify the problem.