maven review (advanced + advanced)

maven junior

1. What is manve?

Manve is a project management tool. The pom file can manage the construction of the project, report and document through a small piece of information through the addition and dependency management system. It contains a project object model, a set of standard collections, and a project Life cycle, a dependency management system, and logic used to run the definition of inserting goals in life cycle stages

The role of manve (what problem can it solve)

  • Project settings follow uniform rules
  • Share in any project
  • Dependency management including automatic updates
  • A large and growing library
  • Extensible. Can easily write Java or scripting language plug-ins
  • Requires little or no additional configuration for instant access to new features
  • Build project, manage jar package
  • jar package dependency compilation test deployment

maven coordinates

Coordinates: Every jar package or maven project has a unique ID on the network
Coordinates (GAV)

  1. groupId company or organization domain name in reverse order (warehouse: package name)
  2. artifactId project name or module name (warehouse: project name)
  3. version version number (warehouse: version number)
<groupId>com.czxy</groupId> <artifactId>maven_test2</artifactId> <version>1.0-SNAPSHOT</version>

If installed in a warehouse, the location of the warehouse is: warehouse/com/czxy/maven_test2/1.0-SNAPSHOT

Common Maven commands
Insert picture description here

clean: clear the target directory
compile: generate the target directory
package: generate the jar package in the target directory
install: install the generated jar package to the local warehouse

Maven advanced

1. Dependency conflict resolution
The dependency in manve:
Direct dependency: A depends on B
Indirect dependency: A depends on BB depends on C, A depends on C indirectly
Insert picture description here

Problem: If a project depends on different versions of another jar at the same time, it may cause jar conflicts. This is the
Jar version conflict problem of transitive dependency .
Insert picture description here

Test code

<!--导入相关依赖包-->

<dependencies>
    <!--引入spring-context,它所以来的包都会导入进来-->
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>5.0.2.RELEASE</version>
    </dependency>

	<dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>4.2.4.RELEASE</version>
    </dependency>
</dependencies>

When the jar conflicts, there are two approaches

1) Maven automatically handles it according to the two mediation principles above

2) Use the exclusions tag to manually exclude unnecessary jars

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>4.2.4.RELEASE</version>
        <!--直接排除-->
        <exclusions>
            <exclusion>
                <groupId>org.springframework</groupId>
                <artifactId>spring-core</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

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

What is the role of the dependencyManagement tag?

The face of numerous dependent, there is a method irrespective path dependent, and other factors can be used to optimize the statement directly locked version
version of this method for determining the dependence member after the locking release declaration order dependent or path-dependent not considered to lock
the The version shall be added to the project, this method is commonly used in enterprise development.
The following configuration is to lock the versions of spring-beans and spring-context:

<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-beans</artifactId>
                <version>5.2.0.RELEASE</version>
            </dependency>

            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-context</artifactId>
                <version>5.2.0.RELEASE</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

You can also extract the version number and use the tag to set it as a variable.

Such as:

<!--版本号-->
    <properties>
        <spring.version>5.2.0.RELEASE</spring.version>
</properties>


    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-beans</artifactId>
                <version>${
    
    spring.version}</version>
            </dependency>

            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-context</artifactId>
                <version>${
    
    spring.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

Inheritance and aggregation

Aggregation 
  When there are multiple projects that need to be packaged into the warehouse (in fact, the current project depends on many projects, so before the current project is executed, you need to install all these dependent projects into the local warehouse), it is too troublesome to execute the install one by one, maven has a method Multiple items can be installed to the local warehouse together. It is aggregation.

E.g:

There are three projects A, B, C need to install, create a new aggreation project for aggregation (make sure that aggreation and the three projects are the same GroupID. This sentence means that if the multiple projects are not the same GroupID, Can't use aggregation?).

Then modify the pom file of the aggreation project:
  1. Modify the packaging method from jar to pom:

pom
  2. Add tags

 <modules>
         <module>../A</module>
         <module>../B</module>
         <module>../C</module>      
    </modules> 

What does this.../ mean? Refers to the root directory of maven?

It should be the upper-level directory of the current project pom, which is actually the folder where all projects are stored (that is, the root directory of the maven project), and then use /A /B /C to represent the relative path of the current project and these three projects

Then execute the install command on the aggreation project, then the projects A, B, and C are all packaged to the local warehouse.

Implementation of aggreation projects such as test, A, B, C projects will also be executed. Even if there is a dependency between ABC, such as B depends on A, without having to execute and install A first, B will also be executed. This is the advantage of aggregation.

After configuring the aggregation project, you only need to operate the aggregation project, and the items inside will be operated. Regardless of whether there are dependencies between these projects.

Inheritance :
Why use inheritance:

If the configuration in pom.xml is for multiple projects, there will inevitably be repeated configurations of dependencies and plug-ins. In the object-oriented world, programmers can use class inheritance to eliminate duplication to a certain extent. In the world of Maven, there is a similar

The mechanism allows us to extract duplicate configurations, which is the inheritance of pom

Guess you like

Origin blog.csdn.net/weixin_43464372/article/details/107778204