Maven 最佳实践

时间:2023-03-08 16:22:40
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 目标可以识别一个项目中关于依赖的两类问题:

  1. 直接就使用但未声明的依赖;(项目可以编译因为它也得到了所需的依赖)
  2. 声明了但没有使用的依赖。

你可以设置如果有任何依赖相关的警告时构建失败,参见: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/