Maven’s life cycle

Maven has three separate life cycles: Clean, Default, and Site.

  • The purpose of the clean lifecycle is to clean up projects;
  • The purpose of the default (Build) life cycle is to build the project;
  • The purpose of the site lifecycle is to create project sites.
Clean Life cycle

The purpose of the Clean life cycle is to clean up projects, and it consists of three phases.

  • Pre-clean: indicates the work to be completed before the cleaning.
  • Clean: Clears the files generated during the last build, such as the compiled class files.
  • Post-clean: indicates the work to be completed after the cleaning.
Default Life Cycle

The Default life cycle defines the execution steps required to build a project. It is the most core part of all life cycles and contains the phases described in the following table. Only some commonly used phases are listed below

The name of the role
validate Verify that the project structure is in order and that the necessary configuration files exist
compile Compile the source code in the project
test Run the test case
package Package compiled classes and resources, such as JAR /war/ POM
verify Check whether the tested package is intact
install Install the packaged package into a local repository for sharing with other local projects
deploy The package will be installed to the private server, convenient for all programmers to share
Site Life Cycle

The purpose of the site life cycle is to create and publish a project site that, depending on the plug-in, generates HTML files containing the project’s dependencies, descriptions, Java documentation, and even source code.

Modular development

Service split

All functions written in one project face the following problems:

  1. The code is bloated and the application takes a long time to start.
  2. Application fault tolerance is poor, a small function of the program error may lead to the continuous consumption of system resources, and finally the whole system down;
  3. Scaling is difficult, and the performance of a single application can be expanded only for the entire application, resulting in a waste of computing resources.
  4. The regression testing cycle is long, and fixing a small bug may require regression testing for all critical businesses.
  5. Development collaboration is difficult. In a large application system, dozens or even hundreds of developers are all maintaining the same set of code, and the complexity of code merge increases dramatically.

Module aggregation and inheritance

The module aggregate

  1. Packaging Is of the POM type
 <packaging>pom</packaging>
Copy the code
  1. Defines the name of the module to be associated with when building
 <modules>
     <module>dao</module>
     <module>service</module>
     <module>web</module>
 </modules>
Copy the code

Module inheritance

Specify parent project coordinates (GAV) in child modules

<parent>
    <artifactId>MyMaven</artifactId>
    <groupId>com.eponine</groupId>
    <version>1.0 the SNAPSHOT</version>
</parent>
Copy the code

Dependency management

Manage dependencies in the parent project so that versions can be unified. The child module only needs to inherit dependencies from the parent project.

Dependency management upgrade

The child project inherits all dependencies without

and inherits the specified dependencies after use

  1. Parent engineering use<dependencyManagement>Tags manage dependencies
  2. A child project declares a dependency that it inherits from a parent project by omitting the version number

Property (version) management

A large number of dependencies are managed in the parent project, and one set of dependencies may need to use the same version, such as Spring-related dependencies

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>5.2.12. RELEASE</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-jdbc</artifactId>
    <version>5.2.12. RELEASE</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-test</artifactId>
    <version>5.2.12. RELEASE</version>
</dependency>
Copy the code

In the Maven parent project, you can use the tag to manage properties uniformly, and use ${} in dependencies to reference the defined version of the property 

<properties>
    <spring.version>5.2.12. RELEASE</spring.version>
</properties>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>${spring.version}</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-jdbc</artifactId>
    <version>${spring.version}</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-test</artifactId>
    <version>${spring.version}</version>
</dependency>
Copy the code

Rely on the conflict

A dependency conflict is when a project depends on a jar package that has multiple versions, resulting in a package version conflict

Dependency conflicts are often caused by indirect dependencies between packages. Each explicitly declared package depends on some other implicit package, which maven indirectly introduces, causing class package conflicts

Resolution of dependency conflicts

  1. Maven’s own solution principles
  • First, declare the principle of priority
  • Shortest path matching rules
  1. Manual dependency exclusion
  2. Version of the lock
First, declare the principle of priority

Direct introduction: post-defined overrides previous

Indirect introduction: First declaration first principle: first definition first

Shortest path matching rules

Manually removing dependencies

Discard the 5.2.12 conflicting dependencies and use the 5.1.18 dependencies

<dependencies>
    <! First declaration principle, who first declaration, use whose version -->
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-webmvc</artifactId>
      <version>5.2.12. RELEASE</version>
      <! -- Manual dependency exclusion -->
      <! -- Here we exclude 5 dependencies where conflicts occur -->
      <exclusions>
        <exclusion>
          <groupId>org.springframework</groupId>
          <artifactId>spring-expression</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.springframework</groupId>
          <artifactId>spring-core</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.springframework</groupId>
          <artifactId>spring-aop</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.springframework</groupId>
          <artifactId>spring-beans</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.springframework</groupId>
          <artifactId>spring-context</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-context</artifactId>
      <version>5.1.18. RELEASE</version>
    </dependency>

  </dependencies>
Copy the code
Version of the lock

Using

for version management in a parent project is version locking