maven学习随笔

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

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

【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中配置中央仓库

 在pomx.xml中配置repositories元素，可以设置项目的远程仓库，可以设置一个，也可以设置多个远程仓库。命

5、生命周期和插件

1、生命周期

声明 就是项目构件的生命周期。maven有三套生命周期，它们之间相互独立，不会互相影响。

2、clean生命周期

clean生命周期的目的是情理项目。它包含三个阶段。

（1）pre-clean执行一些情理钱需要完成的工作。

（2）clean情理上一次构建生成的文件。

（3）post-clean执行一些清理后需要完成的工作。

3、default生命周期

default生命周期定义了真正构建是所需要执行的所有步骤，它是所有生命周期中最核心的部分。

（1）validate

（2）initialize

（3）generate-sources

（4）process-sources 处理项目主资源文件。一般来说，是对src/main/resources目录内内容进行变量替换等工作后，复制到项目输出的主classpath目录中。

（5）generate-resources

（6）process-resources

（7）compile 编译项目的主源码。一般来说是编译src/main/java目录下的java文件至项目输出的主classpath目录中

（8）process-classes

（9）gemerate-test-sources

（10）pricesss-test-sources处理项目测试资源文件。一般来说，是对src/test/resources目录的内容进行变量替换等工作后，复制到项目的输出测试classpath目录中。

（11）test-compile编译项目的测试代码。一般来说，是编译src/test/java目录下的 java文件至项目输出的测试classpath目录中。

（12）test使用但与测试矿建运行测试，测试代码不会被打包或部署。

（13）pacekage 接受编译好的代码，打包成可发布的飞逝，如jar

（14）install 将包安装到maven本地仓库。供本地其它Maven项目使用。

（15）deploy将最终的包复制到远程仓库。供其他开发人员和Maven项目使用。

以上未列举完。

4、site生命周期

site生命周期的目的是建立和发布项目站点，Maven能够基于POM所包含的信息，自动生成一个友好的站点。方便交流和发布项目信息。

（1）pre-site执行一些在生成项目站点之前需要完成的工作。

（2）site 生成项目站点文档

（3）post-site执行一些在生成项目站点之后需要完成的工作。

（4）site-deploy将生成的项目站点发布到服务器上。

编写的比较混乱。将就着看吧