使用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文件的优化会随着项目的进行而进一步修改有大的改动后,再进行说明。