Maven总结

微信公众号：《Java周刊》
欢迎关注、一起学习、一起进步！
最近更新：2018-05-07

1.Maven的工程类型
war包、jar包、pom；
2.Maven核心
1.依赖管理：jar包依赖、工程之间的依赖；
2.项目构建：实现项目的一步构建；
3.工程聚合、继承；
2.1 依赖管理
依赖会被继承，我们可以将多个子模块中相同的依赖配置放到父模块中，子模块就能移除这些配置，简化配置。

上述做法是可行的，但存在问题。我们不能保证所有的子模块都需要相同的依赖，假设有些模块只是一些简单的帮助工具，你从父模块继承那些所有的依赖配置，显然是不合理的。

Maven提供了dependencyManagement，该元素下的依赖声明不会引入实际的依赖，但是该配置是可被子模块继承的，通常都是通过在父模块声明它来达到统一各个模块依赖的版本版本，所以在子模块中配置依赖时也就不需要再定义版本信息。

使用这种依赖管理机制似乎不能减少太多的pom配置，但依然强烈的建议采用这种方式。其主要原因在于在父pom中使用dependencyManagement声明依赖能够统一版本，这样可以降低依赖冲突的几率。
2.1.1 插件管理
Maven提供了pluginManagement元素帮助管理插件。在该元素配置的依赖不会造成实际的插件调用行为，当pom中配置了真正的plugin元素，并且其groupId和artifactId与pluginManagement中配置的插件匹配时，pluginManagement的配置才会影响实际的插件行为。
2.2 聚合
为了能够使用一条命令就能构建多个模块，我们需要创建一个额外的模块，然后通过该模块构建整个项目的所有模块。这个所谓的额外的模块，它本身作为一个maven项目，它必须要有之间的pom，不过同时作为一个聚合项目，其pom又有特殊的地方，对于聚合项目来说它的打包方式packaging的值必须为pom，否则就无法构建。；另外就是元素，这是实现聚合的核心配置。用户可以通过在一个打包方式为pom的maven项目中声明任意数量的module元素来实现模块的聚合。

为了方便用户构建项目，通常将聚合模块放在项目目录的最顶层，其他模块则作为聚合模块的子目录存在，这样当用户得到源码的时候，第一眼发现的就是聚合模块的pom，不用从多个模块中去寻找聚合模块来构建整个项目。

聚合模块的内容仅是一个pom.xml文件。这也是容易理解的，聚合模块仅仅是帮助聚合其他模块构建的工具，它本身并无实质内容。

关于目录结构需要注意的一点是：聚合模块与其他模块的目录结构并非一定要是父子关系。还有另一种平行的目录结构。如果使用的是平行目录结构，pom文件要作相应的修改：

<modules>
    <module>../子模块名称<module>
</modules>

从聚合项目执行maven命令，maven会首先解析聚合模块的pom，分析要构建的模块、并计算出一个反应堆构建顺序，然后根据这个顺序依次构构建各个模块。

在构建过程控制台的日志输出显示的是各模块的名称，而不是artifactId，这也解释了为什么要在pom中配置合理的name字段，其目的是让maven的构建输出更清晰。
2.3 继承
使用maven的聚合特性通过一条命令同时构建多个项目模块，这仅仅解决了多模块maven项目的一个问题。

多模块maven项目的另一个问题是多个模块有很多相同的配置，例如有相同的groupId、version；有相同的spring-core、spring-bean和junit依赖配置等等。对于这种问题我们可以通过maven的继承特性来解决。

面向对象设计中，我们可以建立一种类的父子结构，然后在父类中声明一些字段和方法供子类继承。这样就可以做到“一处声明，多处使用”。类似的，类似地，我们需要创建pom的父子结构，然后在父pom中声明一些配置供子pom继承，以实现“一处声明，多处使用”的目的。

通过继承父模块，在子模块的pom中就不用声明groupId、version，子模块隐式的从父模块继承这两个元素。这也就消除了一些不必要的配置。如果子模块需要使用和父模块不一样的groupId和version，那么用户完全可以在子模块中显示的声明。对于artifactId元素来说，子模块应该显示声明，一方面如果完全继承groupId、artifactId、version，会造成坐标冲突；另一方面，即使使用不同的groupId或version，同样的artifactId容易造成混淆。
2.3.1 可继承的pom元素
groupId: 项目组的id，项目坐标的核心元素。
version: 项目版本，项目坐标的核心元素。
descripton: 项目的描述信息。
organization: 项目的组织信息。
inceptionYear: 项目的创始年份。
url: 项目的url地址。
develops: 项目的开发者信息。
contributors: 项目的贡献者信息。
distributionManagement: 项目的部署配置。
issueManagement: 项目的缺陷跟踪系统信息。
ciManagement: 项目的持续继承系统信息。
scm: 项目的版本控制系统信息。
mailingLists: 项目的邮件列表信息。
properties: 自定义的maven属性。
dependencies: 项目的依赖配置。
dependencyManagement: 项目的依赖管理配置。
repositories: 项目的仓库配置。
build: 包括项目的源码目录配置、输出目录配置、插件配置、插件管理配置。
reporting: 包括项目的包括输出目录配置、报告插件配置等。
2.4 聚合与继承的关系
我们了解到多模块maven项目中聚合与继承其实是两个概念，其目的完全不同。前者主要是为了方便快速构建，后者主要是为了消除重复配置。

对于聚合模块来说，它知道有哪些聚合的模块，但那些被聚合的模块不知道这个聚合模块的存在。

对于继承关系的父pom来说，它不知道有哪些子模块继承它，但那些子模块都必须知道自己的父pom是什么。

如果非要说这两个特性的共同点：那么可以看到，聚合pom与继承关系中的父pom的packaging都必须是pom，同时聚合模块与继承关系中的父模块除了pom之外都没有实际的内容。

在实际项目中，我们发现往往一个pom即是聚合pom，又是父pom，这么做主要是为了方便。一般来说，融合使用聚合与继承完全没有问题。