读《Maven实战》

第一章 Maven简介

1.1 何为Maven

1. Maven 这个词可以翻译为“知识的积累”、“专家”、“行家”。 
2. Maven的作用：不仅能帮我们自动化的构建，还能够抽象构建过程，提供构建任务实现；它跨平台，对外提供一致的接口。还是一个依赖管理工具和项目信息管理工具。

第二章 Maven的安装与配置

2.1 设置HTTP代理

1. <proxies>   <proxy></proxy>   <proxy></proxy>   </proxies> 里面可以有多个代理，以第一个为准。

2.2 Maven安装的最佳实践

1. 设置MAVEN_OPTS环境变量。
    我们了解到运行mvn命令实际上就是在运行Java命令。所以，运行Java命令上的参数也可以用在mvn上面。所以可以配置一些环境变量。
2. 配置用户范围的setting.xml。
3. 尽量不要IDE内置的Maven,因为那些Maven会比较新，不够稳定。

第三章 Maven使用入门

3.1 编写POM（Project Object Model 项目对象模型）

1. modelVersion：指定当然POM模型的版本。
2. groupId：当前Maven项目隶属的实际项目，不应该对应项目项目所在的组织或者公司。因为，一个公司下会有多个项目。
3. artifactId：项目在组中唯一的ID。
4. scope： 为依赖范围，若依赖范围为test则表示该依赖只对测试有效。默认是compile，表示对主代码和测试代码都有效。

3.2 Maven命令

1. package和install的差别: package操作是以定义的打包方式，默认为jar将主代码打包。而install是会先package打包后，将该包载入本地仓库，供其他项目使用。

第四章 坐标和依赖

4.1 依赖范围

Maven在编译主代码、测试代码、实际运行Maven项目的时候，用的是不一样的classpath。
1. compile：编译依赖范围。没有指定默认使用该范围。 对编译、测试、运行三种classpath都有效。
2. test： 测试依赖范围。只对于测试的classpath有效。如Junit。
3. provided： 已提供依赖范围。对于编译、测试classpath有效。如servlet-api，运行项目已经提供，无需再次引入。
4. runtime： 运行时依赖范围。 对于测试和运行classpath有效。如JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口。
5. system： 系统依赖范围。和provided依赖范围一致。但是使用system范围的依赖时必须通过systemPath元素显示地指定依赖文件的路径。
6. import（Maven 2.0.9及以上）： 导入依赖范围。对三种都没有影响。

4.2 依赖调解

1. 第一原则：路径最近者优先。
2. 第二原则： 第一原则相同时，以在POM文件最先声明的。

4.3 可选依赖

假设：A -》B，B -》X和Y，B对于X和Y都是可选依赖。
那么X和Y不是A的间接依赖。当具体选用某个依赖时，需要A显示声明这一依赖。而不能通过传递性依赖获得。

4.4 最佳实践

可以使用exclusion声明排除一个或多个依赖。
声明exclusion的时候只要groupId和artifactId，而不需要version元素。Maven解析后的依赖中，不可能出现groupId和artifactId相同，但version不同的依赖。

4.5 生命周期和插件

1. 当多个插件目标绑定到同一个阶段的时候，这些插件声明的先后顺序决定了目标的执行顺序。

第五章 聚合与继承

5.1 聚合与继承

1. 聚合的特性就是将多个module聚合在一起构建。
2. <module></module>里面的值都是一个当前POM的相对目录。
3. <relativePath></relativePath>:当父模块在子模块的上一级目录时。
4. 父模块和聚合模块的<type></type>都是pom。
5. 继承主要用来减少相同的配置，但是又由于容易给子模块引入一些不必要的依赖。所以有了dependencyManagement和pluginManagement来管理相同的依赖的配置，如版本等。他们既能让子模块继承到父模块的依赖配置，就只是配置，如果子模块中不引入相应的依赖，这两个Management并不产生实际效果，又能保证子模块的灵活性。

转载于:https://www.cnblogs.com/llQ13/p/11190903.html