1、pom.xml文件中的元素含义

【groupId】 ：定义当前项目隶属的实际项目。首先，Maven项目和实际项目不一定是一对一的关系。比如SpringFramework这一实际项目，其对应的Maven会有很多，如spring-core、spring-context等。这是由于Maven中模块的概念，因此，一个是项目往往会被划分为多个模块。其次，groupId不应该对应项目隶属的组织或公司。原因很简单，一个组织下会有很多实际项目，如果groupId如果只定义到组织级别，而后面我们会看到，artifactId的表达式与java包名的表达凡事类似，通常与与域名反向一一对应。比如在www.hello.com建立一个名为test的项目，那么groupId就应该是com.spring，artifactId为test.

【artifactId】：定义实际项目中的一个Maven项目（模块），推荐的做法是使用实际项目名作为artifactId的前缀。比如上例中的test作为artifactId的前缀。这样做的好处是方便寻找实际构件。在默认情况下，Maven生成的构件会以artifactId作为开头，如mavendemo-hello-1.0.0.jar，使用实际项目名称作为后缀 之后，就能方便从一个lib文件夹中找到某个项目的一组构件。考虑5个项目，每一个都有一个core模块，如果没有前缀，我们会看到很多的core-1.2.jar这样的文件，加上实际项目名前缀之后，便能很容易区分不同项目下的core模块。

【version】： 指定Maven项目当前所处的版本的版本。如上例中的mavendemo-hello的版本是1.0.0。需要注意的是，Maven定义了一套完整的版本规范，以及快照（SNAPSHOT）的概念。

【packaging】：该元素定义了Maven项目的打包方式。首先，打包饭石通常与所生成构件的文件拓展名对应，如上例中packaging为jar。最终的文件名为mavendemo-hello-1.0.0.jar，使用war打包方式的Maven项目，最终生成的构件会有一个.war文件。其次，打包方式会影响到构件的声明周期，比如jar打包和打包会使用不同的命令。最后，当不定义packaging的时候，Maven会使用默认值jar。

【calssifier】:该元素用来帮助定义构建输出的一些附属构件。附属构件与住构件对应，如上例中的主构件是mavendemo-hello.jar，该项目可能还会通过使用一些插件生成如mavendemo-hello-1.0.0-doc.jar、mavendemo-hello-1.0.0-sources.jar这样的一些附属构件，其包含了Java文档和源代码。这时候，javadoc和sources就是这两个附属构件的classifier。这样，附属构件也就是拥有了自己唯一的坐标，还有一个关于classifier的的典型例子是TestNG，TestNG的主构件是急于Java1.4平台的，而它又提供了一个classifier为jdk5的附属构件。注意，不能直接定义项目的classifier，因为附属构件不是项目直接默认生成的，而是由附加的插件帮助生成。

这5个元素中，groupId、artifactId、version是必须的，packaging是可选的，而classifier 是不能定义的。

【type】:依赖的类型，对应于项目坐标定义的packaging。大部分情况下，该元素不必声明，默认为jar。

【scope】：元素为依赖的范围，如果不声明依赖的范围，默认值就是compile,表示该依赖对主代码和测试代码都有效。

【optional】：标记依赖是否可选。

【exclusions】：用来排除传递性依赖。

name元素生命了一个对于用户更为友好的项目名称，不是必须的，设置名称方便信息交流。

dependencicies元素该元素下可包含多个dependency元素，

dependency声明项目的依赖。

2、依赖范围

依赖范围就是用来控制三种的classpath（编译classpath、测试classpath、运行classpath）。Maven有以下几种依赖范围：

（1）compile：编译依赖范围。如果没有指定，默认是使用该依赖范围。使用此依赖范围的Maven依赖，对于编译，测试、运行三种classpath都有效。如spring-core。

（2）test：测试依赖范围。使用此依赖范围的Maven依赖只对测试classpath有效，在编译主代码或者运行项目的使用时将无法使用此类依赖。比如junit。

（3）provide：已提供依赖范围。使用此依赖范围的Maven依赖，对编译和测试classpath有效，但在运行时无效。典型的例子是servlet-api，编译和测试项目的时候需要该依赖，但在项目运行的时候，由于容器已经提供，就不需要Maven重复的引入一遍。

（4）runtime：运行时范围依赖。使用此范围依赖的Maven依赖，对于测试和运行classpath有效，但在编译主代码时无效。典型例子就是JDBC驱动的实现，项目主代码的编译接口只需要JDK提供的JDBC接口，只有在执行测试或者运行项目的时候才需要是想上述接口的具体JDBC驱动。

（5）system：系统依赖范围。该依赖与三种classpath的关系，和provide范围依赖范围完全一致。但是，使用system范围的依赖时，必须通过有啥用特么Path元素显示地指定依赖文件的路径，由于此类依赖不是通过Maven仓库解析的，而且往往与本机系统绑定，可能造成构件的不可移植。因此应该口谨慎使用。systemPath元素可以引用环境变量，如

<dependency>

<groupId>javax.sql</groupId>

<artifactId>jdbc-stdext</artifactId>

<version>2.0</version>

<scope>system</scope>

<systemPath>${java.home}/lib/rt.jar</systemPath>

</dependency>

(6)import(Maven2.0.9及以上)：导入依赖范围。该依赖范围不会对三种classpath产生实际的影响。

3、管理依赖

1、依赖的传递

2、调节依赖

3、排除依赖

如果A依赖B，B隐式依赖C-1.0.1。但是C-1.0.1不稳定，我们想要使用C-1.0.2。那么我们就需要将C-1.0.1依赖排除。使用exclusions元素可以将某个依赖排除。

4、maven仓库

 1、Maven 仓库有三种类型：

• 本地（local）
• 中央（central）
• 远程（remote）

2、本地仓库

Maven 本地仓库是机器上的一个文件夹。它在你第一次运行任何 maven 命令的时候创建。

Maven 本地仓库保存你的工程的所有依赖（library jar、plugin jar 等）。当你运行一次 Maven 构建，Maven 会自动下载所有依赖的 jar 文件到本地仓库中。它避免了每次构建时都引用存放在远程机器上的依赖文件。

Maven 本地仓库默认被创建在 %USER_HOME% （windows、linux、mac的默认用户目录不同，详细的请百度）目录下。要修改默认位置，在 %M2_HOME%\conf 目录中的 Maven 的 settings.xml 文件中定义另一个路径。

一般修改仓库配置是建议修改用户级别的配置，全局的配置（maven安装目录下的setting.xml）不建议修改。

3、中央仓库

Maven 中央仓库是由 Maven 社区提供的仓库，其中包含了大量常用的库。

中央仓库的关键概念：

• 这个仓库由 Maven 社区管理。
• 不需要配置。
• 需要通过网络才能访问。

4、远程仓库

如果 Maven 在中央仓库中也找不到依赖的库文件，它会停止构建过程并输出错误信息到控制台。为避免这种情况，Maven 提供了远程仓库的概念，它是开发人员自己定制仓库，包含了所需要的代码库或者其他工程中用到的 jar 文件。

5、Maven 依赖搜索顺序

当我们执行 Maven 构建命令时，Maven 开始按照以下顺序查找依赖的库：

• 步骤 1 － 在本地仓库中搜索，如果找不到，执行步骤 2，如果找到了则执行其他操作。
• 步骤 2 － 在中央仓库中搜索，如果找不到，并且有一个或多个远程仓库已经设置，则执行步骤 4，如果找到了则下载到本地仓库中已被将来引用。
• 步骤 3 － 如果远程仓库没有被设置，Maven 将简单的停滞处理并抛出错误（无法找到依赖的文件）。
• 步骤 4 － 在一个或多个远程仓库中搜索依赖的文件，如果找到则下载到本地仓库已被将来引用，否则 Maven 将停止处理并抛出错误（无法找到依赖的文件）。

6、pom.xml中配置中央仓库

maven学习笔记