Maven 最佳实践

持续不断地学习maven

Maven是一个很好的工具，但同时也拥有陡峭的学习曲线。因此，将 http://books.sonatype.com/mvnref-book/reference/ 加入到你的书签栏经常翻阅吧。

了解Maven的命令行选项

为了学习Maven的命令行选项，你可以执行mvn -？。下面是一些有用的选项：

-B : 在批处理模式下run maven，这个模式对在类似于Bamboo的可持续集成服务器上使用Maven会很有用处，因为这类系统不允许maven报告下载的进度

-e : 配置maven报告详细的错误信息，这对于在maven运行在一个类似于Atlassion Bamboo的可持续集成的服务器上调试问题很有帮助。

了解标准的Maven插件

在学习一个特定的maven插件的时候，打开这个maven插件的网站仔细阅读这个插件的目标的详细信息。

最好在artifacts和maven项目之间建立一对一的关系

比如，如果你的代码要创建三个jar包，那么最好就有三个maven的项目。如果这三个jar包文件使用了相同的代码，那么就创建第四个maven项目来保存这些代码，然后让原来的三个项目增加一个对公共代码的依赖。

命名你的项目

即使 <name data-preserve-html-node="true" data-preserve-html-node="true">在pom.xml中可选的，你也使用它吧！不要想sonar一样只用一个项目名称。在IDE里面很难去区分两个不命名的项目。

译者注：Sonar 是一个用于代码质量管理的开放平台。通过插件机制，Sonar 可以集成不同的测试工具，代码分析工具，以及持续集成工具

将所有生成的artificts放到target目录

在你执行mvn clean的时候，target目录将会自动删除。因此target目录是个放置所有包括java的class文件、jar包、过程中的临时文件等生成物的最佳地点。maven的插件一般也会把他们临时生成的artifacts放到target目录。

在父pom文件中应用dependenceManagement部分来避免子项目中重复的依赖信息

maven的dependenceManagement允许父pom文件来定义那些可能被子项目重用的依赖。这会避免重复依赖；如果没有dependenceManagement，每个子项目都需要定义自己的依赖，这会包含重复的版本信息、重复的scope信息、重复的依赖类型信息。比如，假设有个多模块的java项目都需要依赖Junit来做单元测试。为了表示这个项目对junit的依赖，父pom文件可以使用一个想下面的dependencyManagement：

xml

junit

junit

4.8.1

test

    需要注意的是，每一个需要junit的子项目必须还要声明对junit的依赖。关于版本和scope的信息就可以被省略掉，这样的话就可以在避免重复的同时保证整个项目使用相同的依赖了。
    子项目的pom文件如下
```xml```
<dependencies>
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
  </dependency>
</dependencies>

在开发时用SNAPSHOT

SNAPSHOT版本是一种使用习惯，它带来了显而易见的好处，具体如下：

它降低了资源的需求。比如，它降低了Nexus服务器对磁盘空间的使用；

它减轻了独立项目生成带来的频繁变化。比如，有一个A项目依赖B项目，两个项目同时在开发。A项目可以声明一个B项目的SNAPSHOT版本的依赖，这样在B每次构建的时候A项目就不用每次都修改它的依赖了。

用maven的依赖插件的分析结果来帮助你识别项目中的依赖管理问题

maven依赖插件（Maven Dependency Plugin）的analyze 目标可以识别一个项目中关于依赖的两类问题：

直接就使用但未声明的依赖；（项目可以编译因为它也得到了所需的依赖）
声明了但没有使用的依赖。

你可以设置如果有任何依赖相关的警告时构建失败，参见：http://maven.apache.org/plugins/maven-dependency-plugin/examples/failing-the-build-on-dependency-analysis-warnings.html

使用未声明的依赖

有如下的假定：

A项目使用了来自B和C项目的类；

A只声明了一个B项目的依赖；

B项目也使用了C项目的类；

B项目声明了以一个C项目的依赖。

这种情况存在一个潜在的问题，因为A依赖B，B依赖C，A项目只有在B项目移除了对C项目的引用后才能编译。如果是SNAPSHOT版本的话问题将会更加严重。

当对A项目用mvn dependency:analyze进行分析时，maven将会有如下输出：

[WARNING] Used undeclared dependencies found:

[WARNING] com.avaya.ace.aaft:foundation_services_client_api:jar:6.2.0-SNAPSHOT:compile

A项目直接声明一个对C项目的引用就会解决这个问题。

没有使用的依赖声明

如果一个项目声明了一个依赖，但没有使用它，mvn dependency:analyze会有如下输出：

[WARNING] Unused declared dependencies found:

[WARNING] com.gigaspaces:gs-openspaces:jar:7.1.1-b4534:compile

在POM文件移除这个依赖声明就可以解决这个问题。

未使用的依赖一般是开发者没有搞清楚maven dependenceManagement的原理造成的。

使用maven依赖管理而不是写普通的代码

例如,如果一个Maven项目取决于由另一个Maven项目生成的zip文件,那么使用第二个项目创建一个Maven artifact、使用Maven的依赖,而不是使用相对路径

使用maven依赖管理而不是使用subversion的externals

比如，有一个Maven项目依赖的资源存储在另一个项目的存储库,那么使用第二个项目创建一个Maven artifact，然后使用Maven依赖来使第一个项目访问。

不要自己写maven的代码来复制或者解压文件

使用maven标准的插件来替代。

原文地址

http://www.kyleblaney.com/maven-best-practices/