This is the third day of my participation in the August More text Challenge. For details, see:August is more challenging

preface

Through the previous understanding, we have a certain understanding of MAVEN, the project management tool. Next, we will explore some advanced application skills of MAVEN combined with the project. If you are not familiar with the basics, you can quickly go through these two articles: Understanding and Installing Maven Basics, And Managing Maven dependencies and Lifecycle and Plug-ins.

The aggregation

As we all know, Maven is a project management tool with its own local repository, and various resources are stored in the local repository. These resources are not only jar packages provided by some third parties. When we package our projects and upload them to the local repository through install, This project will then have the same features as those third-party JARS that other projects can bring in via coordinates and use.

When our project consists of multiple modules and modules developed by different colleagues in charge of maintenance, when B modules do the revised directly uploaded to the local repository, A module is not notified in advance, not timely adjusted, so will lead to the whole project is an error, cause an accident, so I often approach is to create an empty module pom project, It is responsible for the completion of the unified management of all modules, unified construction.

When we need to release the POM project directly, the project will be compiled and packaged according to the order of dependencies at one time. If there is a conflict, it will be exposed in advance, so that the project will not fail.

Effect of polymerization

Build Maven projects quickly, building multiple projects/modules at once

Make way

  • Create an empty module with a packaging type defined aspom
   <packaging>pom</packaging>
Copy the code
  • Defines the association between building other modules when the current module is built<modules></modules>
<modules>
    <module>bookcase-common</module>
    <module>bookcase-coupon</module>
    <module>bookcase-member</module>
    <module>bookcase-order</module>
    <module>bookcase-product</module>
    <module>bookcase-ware</module>
    <module>bookcase-gateway</module>
    <module>bookcase-third-party</module>
    <module>renren-fast</module>
    <module>bookcase-search</module>
</modules>
Copy the code

inheritance

When our project relies on more and more resources, it is possible for resources and resources to rely on different versions of the same resource. If not controlled, the whole project will eventually have a variety of chaotic versions, and even cause conflicts and project errors. In view of the above problems, we can use the poM project created before, we can unify the control of version here, other services are based on the POM project version, if really need, in their own project IN the POM file to modify the version, will not affect other projects.

The role of inheritance

Implement the configuration in the child project that follows the parent project

implementation

1. Define dependencies and versions in the parent project POM file

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.elasticsearch.client</groupId>
            <artifactId>elasticsearch-rest-high-level-client</artifactId>
            <version>${elasticsearch.version}</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
 </dependencies>
</dependencyManagement>
Copy the code

As you can see, my

tag is not a specific version, but a variable. This is actually a convenient way for Maven to provide a property. We can configure the specific version information in one place, so that we can upgrade the project later

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <java.version>1.8</java.version>
    <spring-boot.version>2.2.6. RELEASE</spring-boot.version>
    <spring-cloud.version>Hoxton.SR9</spring-cloud.version>
    <spring-cloud-alibaba.version>2.2.1. RELEASE</spring-cloud-alibaba.version>
    <mybatis-plus.version>3.3.2 rainfall distribution on 10-12</mybatis-plus.version>
    <mysql.version>8.0.20</mysql.version>
    <lombok.version>1.18.12</lombok.version>
    <springfox-swagger2.version>2.7.0</springfox-swagger2.version>
    <springfox-swagger-ui.version>2.7.0</springfox-swagger-ui.version>
    <fastjson.version>1.2.47</fastjson.version>
    <openfeign.version>2.2.5. RELEASE</openfeign.version>
    <elasticsearch.version>7.4.2</elasticsearch.version>
</properties>
Copy the code

2. The child project declare the coordinates and location of the parent project, and then can directly reference the dependencies in the husband project, and can not write the version number

The statement

<parent>
    <artifactId>bookcase</artifactId>
    <groupId>com.yang.bookcase</groupId>
    <version>0.0.1 - the SNAPSHOT</version>
    <relativePath/>
</parent>
Copy the code

reference

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

conclusion

Inheritance vs. aggregation

  • Function:
    • Aggregation is used to build projects quickly
    • Inheritance is used to quickly configure dependencies
  • Similarities:
    • Both aggregate and inherited POM packaging are POM and can be placed in a SINGLE POM
    • Aggregation and inheritance belong to the management module and have no actual module content
  • The difference between
    • Aggregation is the configuration relationship in the parent project, and the parent project can sense which modules participate in the aggregation
    • Inheritance is a configuration relationship in a submodule. A parent module has no sense of which submodules inherit from it