Dependency, aggregation and inheritance of Maven core concepts

Macro Chart

One, dependence

The jar packages that we rely on in our project can be introduced in a way that relies on the addition of dependency child elements under the dependencies element.

   <dependency>      <groupId>junit</groupId>      <artifactId>junit</artifactId>      <version>4.10</version>    </dependency>

1. Scope of dependence

By controlling the scope of dependencies, you can specify at what stage the dependency is valid.

<dependency>      <groupId>junit</groupId>      <artifactId>junit</artifactId>      <version>4.10</version>      <scope>test</scope>    </dependency>

Some of Maven's range of dependencies (<scope></scope>)

Name	Valid range
Compile	Compile, test, run. Default range of dependencies
Test	Tests, such as JUnit
Runtime	Run, such as JDBC
Provided	Compile, test, such as Servletapi
System	Compile, side four, dependent on system variables

2. Dependency with transitive

2.1 Rules for dependency passing

Rules-the same level, first with the first, the level is different, with the least level of

Explanation: The level (dependent level) is the same, in order, depending on the first (level 0), if the hierarchy (level >0), first depends on the lowest level;

2.2 Two ways to remove dependencies

Selective dependency

Use <optional> to remove this dependency transfer feature directly in dependency, that is, if other project references set up the dependent project, the commons-longging will not be relied upon. For example, if you configure commons-logging dependency in Project A, and if Project B relies on project A, then Project B will not rely on commons-logging at this time.

<!--exclude dependencies-  <dependency> <groupId>commons-logging</groupId> <artifactId> Commons-logging</artifactid> <version>1.1.1</version> <optional>true<optional> < /dependency>

Exclude dependencies

If a third-party jar package does not use <optional> to remove dependency transitivity, then we can use the <exclusion> element declaration to exclude dependencies in the current project. For example, a Spring-core dependency is configured in Project A, and if Project B needs to refer to project A, but does not need a commons-logging package at the same time, use the <exclusion> element exclusions. This usage can be carved to solve the problem of package version conflicts.

<!--exclude dependencies-<dependency>            <groupId>org.springframework</groupId>          <artifactid >spring-core</artifactId>             <exclusions>                    <exclusion>                            <groupId> commons-logging</groupid>                            <artifactId>commons-logging</artifactId>                    </exclusion >            </exclusions></dependency>

Second, aggregation

A project is often made up of multiple modules, and building commands for each module is a tedious and error-prone task when it comes to building, so MAVEN's aggregation capabilities enable us to build all of our modules by completing a build command .

The aggregation capabilities of Maven can integrate all the modules to be built through a parent module, declare the package type of the parent module as POM, and centralize the modules into the parent pom by <modules>.

  <!--aggregate the three modules together, <module></module> the middle content is the relative path of the Submodule project name--  <modules>          <module> .. /user-core</module>          <module> /user-log</module>          <module> /user-service</module>  </modules>

Principle: The parent type module, does not need to have the source code and the resource file, namely, does not have the Src/main/java and the Src/test/java directory. Maven first parses the POM file of the aggregation module, analyzes the modules to be built, and calculates the order of execution of the modules through the dependencies of each module, building the modules in turn based on this potential relationship.

Iii. inheritance

The concept of inheritance in Maven is consistent with the concept of object-oriented inheritance, eliminating repeated encoding behavior through inheritance . Here, we can also use a parent module to complete the inheritance relationship between the parent module and the Submodule shared dependency. Parent Module

The parent module's POM file declaration, as usual, extracts the public place, and the submodule needs to inherit the parent module.

<!--inherit User-parent's parent module--><parent>          <groupId>com.tgb.bobo</groupId>          < artifactid>user-parent</artifactid>          <version>0.0.1-SNAPSHOT</version>          <!-- The absolute path to inheritance is the Pom file          ---<relativepath> /user-parent/pom.xml</relativepath>  </parent> <!--declaration of this module--  <artifactId> User-service</artifactid>   <packaging>jar</packaging>

Not all POM elements can be inherited, and table 3 is a list of inheritable elements:

There are some common and potential links between aggregation and inheritance, and in practical applications, the parent module of the aggregation module and the inherited parent module are often defined as the same.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Dependency, aggregation and inheritance of Maven core concepts