Maven核心概念_maven的核心是什么?-CSDN博客

本文链接：https://blog.csdn.net/weixin_49018131/article/details/107571580

一、Maven坐标

1.1、什么是坐标？

　　在平面几何中坐标（x,y）可以标识平面中唯一的一点。

1.2、Maven坐标主要组成

groupId：组织标识（包名）
artifactId：项目名称
version：项目的当前版本
packaging：项目的打包方式，最为常见的jar和war两种

样例：

1.3、Maven为什么使用坐标？

Maven世界拥有大量构建，我们需要找一个用来唯一标识一个构建的统一规范。
拥有了统一规范，就可以把查找工作交给机器。

二、依赖管理

2.1、依赖配置

　　依赖配置主要包含如下元素：

 1     <!--添加依赖配置-->
 2     <dependencies>
 3         <!--项目要使用到junit的jar包，所以在这里添加junit的jar包的依赖-->
 4         <dependency>
 5             <groupId>junit</groupId>
 6             <artifactId>junit</artifactId>
 7             <version>4.9</version>
 8             <scope>test</scope>
 9         </dependency>
10         <!--项目要使用到Hello的jar包，所以在这里添加Hello的jar包的依赖-->
11         <dependency>
12             <groupId>me.gacl.maven</groupId>
13             <artifactId>Hello</artifactId>
14             <version>0.0.1-SNAPSHOT</version>
15             <scope>compile</scope>
16         </dependency>    
17     </dependencies>

2.2、依赖范围

　　首先需要知道,Maven在编译项目主代码的时候需要使用一套classpath. 在执行测试的时候会使用另外一套classpath.实际运行Maven项目的时候,又会使用一套classpath

　　依赖范围scope用来控制依赖和编译，测试，运行的classpath的关系. 主要的是三种依赖关系如下：
　　　　1.compile： 默认编译依赖范围。对于编译，测试，运行三种classpath都有效
　　　　2.test：测试依赖范围。只对于测试classpath有效
　　　　3.provided：已提供依赖范围。对于编译，测试的classpath都有效，但对于运行无效。因为由容器已经提供，例如servlet-api
　　　　4.runtime:运行时提供。例如:jdbc驱动

　　compile （编译范围）

　　compile是默认的范围；如果没有提供一个范围，那该依赖的范围就是编译范围(包括编译，测试，运行，打包都能用)。编译范围依赖在所有的classpath 中可用，同时它们也会被打包。

　　provided （已提供范围）

　　provided 依赖只有在当JDK 或者一个容器已提供该依赖之后才使用（编译，测试可用）。例如，如果你开发了一个web 应用，你可能在编译 classpath 中需要可用的Servlet API 来编译一个servlet，但是你不会想要在打包好的WAR 中包含这个Servlet API；这个Servlet API JAR 由你的应用服务器或者servlet 容器提供。已提供范围的依赖在编译classpath （不是运行时）可用。它们不是传递性的，也不会被打包。

　　runtime （运行时范围）

　　runtime 依赖在运行和测试系统的时候需要（运行时才可用），但在编译的时候不需要。比如，你可能在编译的时候只需要JDBC API JAR，而只有在运行的时候才需要JDBC
驱动实现。

　　test （测试范围）

　　test范围依赖在一般的编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用。

　　system （系统范围）

　　system范围依赖与provided 类似，但是你必须显式的提供一个对于本地系统中JAR 文件的路径。这么做是为了允许基于本地对象编译，而这些对象是系统类库的一部分。这样的构件应该是一直可用的，Maven 也不会在仓库中去寻找它。如果你将一个依赖范围设置成系统范围，你必须同时提供一个systemPath 元素。注意该范围是不推荐使用的（你应该一直尽量去从公共或定制的 Maven 仓库中引用依赖）。

最左边一行表示第一直接依赖范围，最上面一行表示第二直接依赖范围，中间的交叉单元格则表示传递性依赖范围。

仔细观察上面表格，我们发现这样的规律：

当第二直接依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致；
当第二直接依赖的范围是test的时候，依赖不会得以传递；
当第二直接依赖的范围是provided的时候，只传递第一直接依赖的范围也为provided的依赖，切传递性依赖的范围同样为provided；
当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递性依赖的范围为runtime。

2.3、传递性依赖

　　MakeFriends.jar直接依赖于HelloFriends.jar，而HelloFriends.jar又直接依赖于Hello.jar，那么MakeFriends.jar也依赖于Hello.jar，这就是传递性依赖，只不过这种依赖是间接依赖，如下图所示：

2.4、可选依赖

当project-A 依赖project-B, project-B 依赖project-D时

<dependency>
  <groupId>sample.ProjectD</groupId>
  <artifactId>ProjectD</artifactId>
  <version>1.0-SNAPSHOT</version>
  <optional>true</optional>
</dependency>

所以当project-B的依赖的D项目设置<optional>true</optional>时, project-A中如果没有显式的引入project-D, 则project-A不依赖project-D, 即project-A可以自己选择是否依赖project-D

默认<optional>的值为false, 及子项目必须依赖