From the beginning of this article, we began to contact and become familiar with a concept-"component", "In the Maven world, the output of any dependency, plugin or project construction can be called a component." That is what we usually say Jar package, war package, ear package, etc. can be called components. In Maven, the logical representation of components is coordinates, and the physical representation is files in a "warehouse". This article mainly introduces the content of Maven coordinates and the processing of referencing other components to the project.
Maven coordinates (Coordinate)
"Maven defines such a rule: any component in the java world can be uniquely identified using Maven coordinates"When developing your own project, you must also define the coordinates, which is mandatory by Maven. Only then can other projects reference the components generated by the project.
Maven coordinates contain the following elements:
required
groupId: The actual project that the current Maven project belongs to. An actual project may correspond to multiple Maven projects (modules).
Similar to java package name, one-to-one correspondence with domain name reverse
artifactId: A Maven project (module) in the actual project.
Recommended practice: Use the actual project name as a prefix to facilitate finding the actual component
version: current version
Optional
packaging: defines the packaging method, usually corresponding to the extension of the generated component, the default value is jar
classifier: help define some auxiliary components output by the component, which cannot be directly defined (generated by the help of additional plugins)
Dependency management
We will refer to many other projects in the java project . These projects are added to our project (accurately added to the classpath) in the form of jar, war, ear, etc., so that we can use the functions provided by the period The project we refer to is called dependency. Before there was no Maven, we had to download the package files of each project and put them into our project, which was time-consuming and laborious, and it was easy to cause conflicts between various dependent versions. Based on Maven coordinates, the dependency management function provided by Maven largely solves these problems.
In the Maven project, we want to add dependencies, all we need to do is add the following configuration in the pom file (for specific examples, please refer to
"Maven combat" learning summary (2)-the most basic exercises )
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.7</version>
<scope>test</scope>
</dependency>
</dependencies> The above simple configuration is to introduce the junit jar file into our project. If multiple components are referenced, add multiple dependency subnodes under the dependencies node.
Detailed configuration
required
groupId, artifactId, version: uniquely determine a dependent component
Optional
(1) type: dependent type, corresponding to packaging in coordinates, also defaults to jar
(2) scope: dependent scope, control which classpath the dependency is added to
Three classpaths--Compile the project main code, (compile, execute) test, run configuration values: compile (default): all three classpaths are valid test: test classpath is valid (JUnit) provided: compile and test classpath is valid (servlet-api) runtime: Effective test and operation (JDBC interface and driver) system: system dependent range, same as provided, but bound to the local system, it is not recommended to use import: import dependent range, will not affect the three classpaths, later articles Will explain
(3) optional: whether the dependency is optional
When the first directly dependent project implements different features, these features are mutually exclusive, ( will not appear at the same time ) can be marked:
<optional>true</optional>
Optional dependencies are not passed, so it is necessary to display the dependencies required to declare the features to be used in the target project.
(4) exclusions: exclude transitive dependence
Project A depends on project B, and project B depends on project C. For some reason, we don't need C to be passed, but to display the statement
Transitive dependence
As the name implies, transitive dependencies are "dependent dependencies", which means that a dependency of our project may also depend on other components ( our project-> dependent components-> other components ). At this time, this "other component" It may also become a dependency of our project. Why is it "very likely", because the transitive dependence can be established depends on the two directly dependent dependencies.
A对于B是第一直接依赖，B对于C是第二直接依赖，A对于C是传递性依赖。
也就是说，现在的问题是：我们我们需要明确这里的传递性依赖的依赖范围是什么？这样我们才能确定这个依赖会引入到哪种classpath下，对我们的程序具体会产生怎样的影响。
上图为由第一直接依赖、第二直接依赖组合决定的传递性依赖情况（“-”代表不会出现传递性依赖）。
优点：简化了依赖的声明、一般只关心第一直接依赖，不必理会传递性依赖。
缺点：此机制可能导致依赖版本冲突的问题。对于此Maven的依赖调解（Dependency Mediation）机制给出了Maven的解析原则：近者优先。
①A-->B-->C-->X(5.0) A-->D--X(4.0) ——路径：前者为3，后者为2，则4.0会被A所依赖
②A-->B-->Y(6.0) A-->C-->Y(7.0) ——声明：当路径相同时，POM文件中声明靠前者会传递
常用命令
mvn dependency:list ——查看当前项目的已解析依赖（Resolved Dependency：Maven根据自身规则调整后的依赖关系）
mvn dependency:tree ——查看当前项目的依赖解析树，可查看某项依赖的具体解析路径。
mvn dependency:analyze ——帮助分析出项目中有必要直接引入、有可能无用的依赖 等功能。
Maven小结
本篇文章主要介绍Maven中构件的逻辑表示方式——坐标，以及基于此的Maven项目依赖管理功能。分析了依赖的配置、传递性依赖的概念、优点、缺点以及一些常用命令，相信有了这些基础，可以应对项目中依赖的相关应用及使用问题。下篇我们将介绍构件的物理管理方式——仓库。
