MAVEN使用最佳实践

MA VEN使用最佳实践
闫国玉2009-10-26
本文档介绍一些在使用Maven过程中不是必须的，但十分有用的实践。

目录
1.1设置MA VEN_OPTS环境变量 (2)
1.2配置用户范围SETTINGS.XML (2)
1.3不要使用IDE内嵌的M A VEN (3)
1.4搭建内部仓库管理器 (4)
1.5尽可能的遵循M A VEN的约定 (5)
1.6优先编译被依赖的模块 (5)
1.7利用M A VEN插件创建项目 (5)
1.1设置MAVEN_OPTS环境变量
当Maven项目很大，或者你运行诸如mvn site 这样的命令的时候，maven运行需要很大的内存，在默认配置下，就可能遇到java的堆溢出。

解决的方法是调整java的堆大小的值。

Windows环境中
找到文件%M2_HOME%\bin\mvn.bat ，这就是启动Maven的脚本文件，在该文件中你能看到有一行注释为：
@REM set MA VEN_OPTS=-Xdebug -Xnoagent piler=NONE...
它的意思是你可以设置一些Maven参数，我们就在注释下面加入一行：
set MA VEN_OPTS= -Xms128m -Xmx512m
之后，当你运行Maven命令如mvn -version 的时候，你会看到如下的输出：
E:\test>mvn -version
E:\test>set MA VEN_OPTS= -Xms128m -Xmx512m
Maven version: 2.0.9
Java version: 1.6.0_07
OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows"
我们看到，配置的Maven选项生效了，OutOfMemoryError也能得以相应的解决。

Linux环境中
也可以通过设置环境变量解决该问题，如，编辑文件/etc/profile 如下
MA VEN_OPTS=-Xmx512m
export JA VA_HOME MA VEN_HOME MA VEN_OPTS JA V A_BIN PATH CLASSPATH
如果你使用Hudson
用Hudson + Maven做持续集成，并不幸也遇到了类似的错误，那么上述两种方式都将不再起作用了，因为Hudson使用自己的maven-agent来启动Maven，不会去调用Maven的脚本，自然相应的配置也就无效了。

好在Hudson也给为我们提供了配置点，在Hudson的项目配置页面中，有一块Build区域，这里我们已经设置了Root Pom和Goals。

注意该区域的右下角有一个"Advanced..."按钮，点击会看到MA VEN_OPTS输入框，这里输入"-Xmx512m"就OK了。

m2eclipse中
类似以上的方法都会失效，所幸m2eclipse提供了配置点。

步骤如下：
项目上右击-> Run As -> Run Configurations -> Maven Build 上右击-> New
这时会看到一个maven运行配置对话框，这里面其它的配置我不多解释了，为了解决内存溢出的问题，我们可以选择第二个TAB: JRE，然后在VM arguments中输入配置如：-Xms128m -Xmx512m。

1.2配置用户范围settings.xml
Maven用户可以选择配置$M2_HOME/conf/settings.xml或者~/.m2/settings.xml。

前者是全局范围的，整台机器上的所有用户都会直接收到该配置的影响，而后者是用户范围的，只有当前用户才会收到该配置的影响。

我们推荐使用用户范围的settings.xml，主要是为了避免无意识地影响到系统中其他用户，当然，如果你有切实的需求，需要统一系统中所有用户的settings.xml配置，则当然应该使用全局范围的settings.xml。

除了影响范围这一因素，配置用户范围settings.xml文件还能够方便Maven的升级。

直接修改conf目录下的settings.xml会造成Maven升级的不便，每次升级到新版本的Maven，我们就需要赋值settings.xml文件，而如果使用~/.m2目录下的settings.xml，就不会影响到Maven安装文
件，升级时就不需要触动settings.xml文件。

1.3不要使用IDE内嵌的Maven
不论是Eclipse还是NetBeas，当我们集成Maven的时候，都会安装上一个内嵌的Maven，这个内嵌的Maven通常会比较新，但不一定很稳定，当然往往也会和我们在命令行使用的Maven 不是同一个版本。

这里又会出现两个潜在的问题，首先，较新版本的Maven存在很多不稳定因素，容易造成一些难以理解的问题。

其次，由于除了IDE，我们也经常还会使用命令行的Maven，如果版本不一致，容易造成构建行为的不一致，这是我们所不希望看到的。

因此，我们应该在IDE中配置Maven插件使用与命令行一直的Maven。

在m2eclipse环境中，点击菜单栏中的Windows，然后选择Perfrences，在弹出的对话框中，展开左边的Maven项，选择Instanllation子项，在右边的面板中，我们能够看到有一个默认的Embedded Maven安装被选中了，点击Add…然后选择我们的Maven安装目录M2_HOME，添加完毕之后选择这一个外部的Maven。

如下图：
NetBeans Maven插件默认会侦测PATH环境变量，因此会直接使用与命令行一致的Maven 环境。

点击菜单栏中的工具，选择选项，选择其他标签栏，再选择Maven子标签栏，你就能看到如下的配置：
1.4搭建内部仓库管理器
仓库管理器有两个服务目的：首先它的角色是一个高度可配置的介于你的组织与公开Maven 仓库之间的代理，其次它为你的组织提供了一个可部署你组织内部生成的构件的地方。

代理Maven仓库有很多好处。

对于一开始使用Maven的情况来说，通过为所有的来自中央Maven仓库的构件安装一个本地的缓存，你将加速组织内部的所有构建。

如果有开发人员想要下载Spring Framework 的2.5版本，并且你在使用Nexus，那些依赖（以及依赖的依赖）只需要从远程仓库下载一次。

如果有一个高速的Internet 网络连接，这看起来没什么大不了，但是如果你一直要求你的开发人员去下载几百兆的第三方依赖，那么真正节省的时间将会是Maven检查依赖新版本以及下载依赖的时间。

通过本地仓库提供Maven依赖服务可以节省数百的HTTP 请求，在大型的多项目构建中，这样可以为一次构件节省几分钟的时间。

除了简单的时间和带宽的节省，仓库管理器为组织提供了一种控制Maven下载的机制。

你可以详细的设置从公开仓库包含或排除特定的构件。

能够控制从核心Maven仓库的下载对于很多组织来说是经常是一个必要前提，它们需要维护一个组织中使用依赖的严格控制。

一个想要标准化某个如Hibernate或者Spring依赖版本的组织可以通过在仓库管理器中仅仅提供一个特殊版本的构件来加强这种标准。

还有一些组织可能关心确保所有外部的依赖拥有和组织的法律规范相容的许可证。

如果一个企业生产了一个分发应用程序，它们可能想要确定没有人不小心添加了一个涉及GPL许可证的依赖。

仓库管理器为那些需要确信总体架构和政策实施的组织提供了这一层次的控制。

除了控制对远程仓库的访问以外，仓库管理器也为Maven的全面使用提供了一些很至关重要的东西。

除非你希望你组织的每一个成员下载并构建一个单独的内部项目，否则你会希望为开发人员和部门之间提供一种共享内部项目构件的快照版本和发布版本的机制。

Nexus为你的组织
提供了这样的部署目标。

在你安装了Nexus之后，你可以开始使用Maven让它部署快照版和发
布版至一个由Nexus管理的定制仓库。

1.5尽可能的遵循Maven的约定
Maven允许你自定义,但不推荐你这么做。

因为一旦你使用这种自定义，习惯Maven约定的人一开始会觉得奇怪。

只有一些特殊的情况，这些自定义手段能帮你解决实际的问题，比如你在处理遗留代码，你没办法改变源码目录结构，这个时候只有让Maven妥协。

其实基本上所有的约定，或者说默认配置，都可以在Maven的超级POM(super pom)中找到。

由于所有的POM都继承了这个超级POM（类似于java中所有类都继承于Object），因此它的默认配置就被继承了。

以Maven 2.0.9为例，你可以在%m2_home%/lib/下看到一个名为maven-2.0.9-uber.jar的文件，打开这个文件，可以找到org /apache/maven/project/pom-4.0.0.xml 这个文件，这就是超级POM。

Maven提供了一套科学的默认配置，它要求你遵循这些配置约定，然后它就会帮你处理日常的事务compile, test, package等等。

使用Maven的时候，你应该尽可能遵循它的配置约定，一方面可以简化配置，另一方面可建立起一种标准，减少交流学习成本。

一旦你习惯了这种约定，你得到的回报是巨大的。

1.6优先编译被依赖的模块
假设一个项目C有两个模块，模块A和模块B，其中模块A依赖模块B。

若你直接编译项目C，Maven本应该先编译模块B，再编译模块A，，因为模块A依赖模块B。

但是不幸的是，Maven这方面支持的并不是那么完美。

所以如果模块B有改动，我们应该先编译模块B，再编译整个项目C。

希望Maven会在未来的版本中改进这个问题。

1.7利用Maven插件创建项目
当我们需要创建一个基于Maven的项目时，我们可以有两种选择。

一种是遵循Maven约定，自己创建项目需要的所有目录和文件（例如pom.xml），但是这种方式是不被推荐的。

因为这种方式需要手动，而我们往往容易在不经意中犯下错误（例如拼写错误）。

我们可以利用Maven的IDE插件（例如m2eclipse）创建一个基于Maven的项目，这种方式会自动生成Maven项目标准
的目录和文件。