Maven Dependency Management Rules

Hard dependencies
refer to that must be introduced by this module.
Transitive dependencies
When importing other modules, because other modules already have dependencies on some jar packages, the dependencies will be automatically imported into this module
. For example, module A has been configured In order to rely on hibernate,
when the dependency of module A is introduced into module B, the dependency of hibernate will be automatically passed into module B.
At this point, there is no need to configure hibernate dependencies in the B module, and those jar packages will be automatically imported according to the passed dependencies!
Dependency exclusion
Due to the feature of transitive dependencies, when you do not want to import the dependencies of the currently introduced module, you can use the exclusion strategy to exclude the corresponding dependencies.

===================================================== ===============

Hard reliance
User-Core module
This module is used to define the entity class, the required dependent JAR package: Hibernate, MySQL-Connector, Log4j, JUnit
Dependent Pack :
mysql-connector is used to use Java to connect to the Mysql database
hibernate is used to persist objects
junit is used for unit testing
log4j is used for logging The coordinates of the
dependent package can be queried through the above URL The
POM.xml configuration is as follows:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>com.gc.user</groupId>
<artifactId>user-core</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>

<name>user-core</name>
<url>http://maven.apache.org</url>

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

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

    <dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.2.6.Final</version>
</dependency>

   <dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.26</version>
</dependency>

    <dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.16</version>
</dependency>

</dependencies>
</project>

===================================================== ===============

Transitive dependency
user-dao module
The main function of this module is to persist objects, of course, it is inseparable from the support of hibernate.
Since this module needs to use the entities in the user-core module, the user-core module needs to be introduced.
Then , the user-core module needs to be deployed. When it is released to the private server, the module can be downloaded locally. jar package
Note :
The user-core module already depends on the hibernate jar package. When the user-dao module introduces the user-core module, the
user-dao module does not need to configure the hibernate dependency in pom.xml, because Dependencies are transitive!
Of course, since the user-core module has dependencies on mysql-connector and log4j, this module will also automatically introduce them!
Note:
Dependency transfer requires two clear points:
1. Whether the dependency is transferred is determined by the scope
2. The transfer is the dependency, not the copying of the jar package from the A module to the B module.
Since the scope of Junit is defined as test, the dependency The relationship will not be passed to another module,
so if you want to use Junit in this module, you also need to configure the dependency on Junit!

pom.xml in this module
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>com.gc.user</groupId>
<artifactId>user-dao</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>

<name>user-dao</name>
<url>http://maven.apache.org</url>

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

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

      <dependency>
<groupId>com.gc.user</groupId>
<artifactId>user-core</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
</dependencies>
</ project>

The scope attribute
of the dependency determines whether the dependency is passed or not, and whether it is entered into the war package
scope=compile, the default scope, the dependency of this scope is the strongest, and is required for compilation, packaging, and running;
scope=test, the dependency will not be passed, and the war will be generated The package will not be imported; the test package does not need to be passed or imported into the war package.
scope=provided, dependencies will not be passed, and will not be imported when generating a war package. Compilation only, useful for testing, similar to test scope, but different starting point. For example, servlet-api, which has been provided by the container, cannot be included. Otherwise, exceptions such as package conflicts will occur.
scope=runtime, no dependencies at compile time, dependencies at runtime

scope=system, import the local jar package, import scope=import

dependency transit
conflict by specifying the local path This module depends on several other modules, and these modules have different dependency versions on a jar package, then this module will Which dependency to use?
Maven will automatically determine according to the "shortest path principle"!
Shortest path principle:
If the local display depends on a jar package, use the local one;
if there is no local display dependency, but a jar package that relies on transitive dependencies:
first determine according to the shortest dependency principle;
if the path lengths are the same, It is determined according to the writing order of
dependencies; the exclusion of dependencies
Maven solves the problem of dependency conflicts based on the shortest path principle, and we can further interfere with the transitive behavior of dependencies through dependency exclusion.
For example, when introducing user-core, I don't want to use user-core's dependency on log4j, then when introducing user-core, just declare the dependencies that need to be excluded:
    
<dependency>
<groupId>com.gc.user</groupId>
<artifactId>user-core</artifactId>
<version>0.0.1-SNAPSHOT</version>
<exclusions>

<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>

dependent Display declaration, control the version of dependencies accurately.
Based on Maven's shortest path principle, it solves the problem of multiple identical dependency conflicts.
Dependency exclusion provides a solution to dependency conflicts.
In addition , we can also directly declare a certain jar in this module. Package dependencies have the highest priority, and conflicts are automatically resolved.

Maven Dependency Management Rules

Guess you like