Maven practice ---- multi-module development --- lack of Jar package, mavenjar
Jar packages in Maven often contain Missing, which is similar to the following situations:
1. The private server does not have the corresponding version number Jar package or the Jar package does not write the version number
2. If the Jar package is wrong, the corresponding dependency will be wrong.
3. The dependent Jar package is introduced and is not managed.
The first and second problems are easy to solve. The third problem still needs to be solved for those who do not understand Maven.
In fact, the third problem exists with the <dependencies> node and <dependencymanagement> node of Maven.
<Dependencies> A node is a project dependent Jar package;
<Dependencymanagement> nodes are dependent management control during multi-module Maven project development.
During multi-module development, the structure information and deployment information can be stored in a parent class using project inheritance. The pom of each subitem inherits the dependency in the pom of the parent class. In this way, the uniform version of the dependencies of all sub-items is solved. To run the project correctly, you must manage these Jar packages in the parent class and define the common dependency in the pom of the Parent Project. This is dependency management.
Let's take a look at the code of the two nodes:
Project
<project> <modelVersion>4.0.0</modelVersion> <groupId>maven</groupId> <artifactId>A</artifactId> <packaging>pom</packaging> <name>A</name> <version>1.0</version> <dependencyManagement> <dependencies> <dependency> <groupId>test</groupId> <artifactId>a</artifactId> <version>1.2</version> </dependency> <dependency> <groupId>test</groupId> <artifactId>b</artifactId> <version>1.0</version> <scope>compile</scope> </dependency> <dependency> <groupId>test</groupId> <artifactId>c</artifactId> <version>1.0</version> <scope>compile</scope> </dependency> <dependency> <groupId>test</groupId> <artifactId>d</artifactId> <version>1.2</version> </dependency> </dependencies> </dependencyManagement></project>
Project B
<project> <modelVersion>4.0.0</modelVersion> <groupId>maven</groupId> <artifactId>B</artifactId> <packaging>pom</packaging> <name>B</name> <version>1.0</version> <dependencyManagement> <dependencies> <dependency> <groupId>maven</groupId> <artifactId>A</artifactId> <version>1.0</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>test</groupId> <artifactId>d</artifactId> <version>1.0</version> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>test</groupId> <artifactId>a</artifactId> <version>1.0</version> <scope>runtime</scope> </dependency> <dependency> <groupId>test</groupId> <artifactId>c</artifactId> <scope>runtime</scope> </dependency> </dependencies></project>
Differences:
The jar in <dependencies> is directly added to the project, and the dependency is managed (if there is a parent pom and a child pom, the Child pom can only passively accept the version of the parent class ); <dependencyManagement> mainly manages versions. It is useful for subclass to inherit the same parent class. It centrally manages dependency versions without adding dependencies. For the versions defined in it, the sub-pom does not have to inherit the version defined by the parent pom.