maven使用基本功——pom文件优化知多少

使用maven进行多模块项目构建时，不得不提的就是pom文件的优化问题。

maven引入了pom继承机制：

首先建一个com.jianxin:test-parent:0.0.1-SNAPSHOT的maven项目。

然后建一个com.jianxin:test-son:0.0.1-SNAPSHOT的maven项目（注二者是同级目录）。

打开test-son的pom.xml文件，在里面输入：

<parent>
		<groupId>com.jianxin</groupId>
		<artifactId>test-parent</artifactId>
		<version>0.0.1-SNAPSHOT</version>
		<relativePath>../test-parent/pom.xml</relativePath>
	</parent>

其中relativePath的默认值为../pom.xml，如果test-son的根目录在test-parent下，那么relativePath就可以不写了。这个路径的重要之处在于，如果专注于一个子模块的开发，那么父模块有极大可能是没有装到本地仓库的，这个路径错了，那么Maven将无法找到父pom，导致构建失败。如果根据relativePath找到父pom，那么就不需要再去检查本地仓库了。

这样，在父模块中定义

<dependencies>
			<dependency>
				<groupId>junit</groupId>
				<artifactId>junit</artifactId>
				<version>4.9</version>
				<scope>test</scope>
			</dependency>
		</dependencies>

在子模块中就会直接加上这个依赖。

问题来了：

设计模式中说过，能聚合不继承，就是因为继承有极大可能会在子类中添加子类不需要的东西。于是maven也采用了一定的机制使得父pom中的元素不被继承，但设置是继承的。

方法就是将dependencies放到dependencyManagement中，如下：

<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.9</version>
			<scope>test</scope>
		</dependency>
	</dependencies>
</dependencyManagement>

那么，子模块在使用到junit的时候，只需要声明groupId和artifactId即可，即：

<dependencies>
	<dependency>
		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
	</dependency>
</dependencies>

有人说这样也不省事啊，但是却不用开发子模块的人员写version和scope，还有就是对于依赖中有可能会设置的exclusions也会继承，那么那些繁杂的设置就不需要再进行重复设置了。

类似的plugins有一个上级标签pluginManagement，设置还是会被继承，相对dependency来说plugins的优势更加明显，plugin的设置是比较多的，而如果plugin如果不这样设置，那么如果更改一点东西，所有的用到plugin都需要更改，那将是一个恶梦。

这里有一个图片，是从maven实战上面截下来的，上面说明了一下都是什么样的元素都会被继承，其实不看也行，我对其总结为只要是重复的，那么就可以试着提一下，因为我们若碰到重复写的配置，那么人家肯定会将这个问题解决掉的，不然maven也不会这么火。

但也有一个元素是这里面没有，但确定能够被继承，那就是profiles也能被继承。

=================================华丽的侵害线=======================================

以上是对于公共部分的优化，对于我们项目中的jar的引用，我们的定义是不将其放到父pom中，而是在子项目中用到哪个就直接复用gav进行定位。但gv是用maven中内置属性project.groupId，project.version，即

<dependencies>
	<dependency>
		<groupId>${project.groupId}</groupId>
		<artifactId>test-other</artifactId>
		<version>${project.version}</version>
	</dependency>
</dependencies>

但还是需要自己设置scope的事，个人感觉这里会埋下什么伏笔，但愿不要出什么问题吧。

=================================华丽的侵害线=======================================

其实优化也不难，在你会用maven将一条线全部构建成功后，其它线的构建也就是这样构建，那么你就可以以这条线的配置为基础，将第三方的全部抽取的父pom中，将子pom中除groupId、artifactId都删了，涉及每个都需要的设置信息，都放到父pom中，最后如果能运行成功，那么就没有什么问题了。

关键是要有看到重复就不舒服的心，pom文件的优化会随着项目的进行而进一步修改有大的改动后，再进行说明。