Maven最佳实践：遵循约定

“一法度衡石丈尺，车同轨，书同文字” —— 《史记·秦始皇本纪》

 

标准的重要性不用我过于强调，想象一下如果不是所有人都基于HTTP开发WEB应用，这个世界会乱成怎样。IE,FF等浏览器之间的差别已经让很多开发者头痛不已。JAVA成功的原因之一就是由于它能屏蔽大部分操作系统的差异，XML流行的原因之一是所有语言都接受它。Maven当然还不能和这些既成功又成熟的技术相比，但所有Maven的用户都应该清楚，Maven提倡的是“约定优于配置（Convention Over Configuration）”，这是Maven最核心的理念之一。

 

Maven是服务于项目生命周期的（有些人说它是build工具，但build只是生命周期的一部分），它试图抽象整个项目生命周期，实际上它也做到了。几乎所有的项目都离不开Mave所定义的生命周期阶段（clean compile test package site...）。不止如此，基于这些阶段，Maven通过插件提供了绝大部分的默认实现，它们不用做任何配置（或者仅需要很少的配置），就能帮你完成你的工作。

 

先看一个简单的基于Ant的build.xml文件。（在Maven之前，你在使用Ant，对吧？如果连Ant都没用，那就更糟了）

<project name="my-project" default="dist" basedir=".">
    <description>
        simple example build file
    </description>
  <!-- set global properties for this build -->
  <property name="src" location="src/main/java"/>
  <property name="build" location="target/classes"/>
  <property name="dist"  location="target"/>

  <target name="init">
    <!-- Create the time stamp -->
    <tstamp/>
    <!-- Create the build directory structure used by compile -->
    <mkdir dir="${build}"/>
  </target>

  <target name="compile" depends="init"
        description="compile the source " >
    <!-- Compile the java code from ${src} into ${build} -->
    <javac srcdir="${src}" destdir="${build}"/>
  </target>

  <target name="dist" depends="compile"
        description="generate the distribution" >
    <!-- Create the distribution directory -->
    <mkdir dir="${dist}/lib"/>

    <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
    <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
  </target>

  <target name="clean"
        description="clean up" >
    <!-- Delete the ${build} and ${dist} directory trees -->
    <delete dir="${build}"/>
    <delete dir="${dist}"/>
  </target>
</project>

这段代码做的事情是清除目录，创建目录，编译源文件，复制依赖至目标目录。这已经十分简单了，但是，为此你还是需要做一些配置：指定源码目录，指定编译字节码目录，指定目标目录，你还需要记住一些ant的配置命令，如delete, mkdir, javac, jar。这看起来没什么问题，至少目前是这样。

 

可能还有用shell脚本在做build这件事情，那么配置可能会比这个复杂一点（笔者不熟悉shell，如果有能将上述代码用shell重写一遍，笔者将不甚感激）。

 

现在说说Ant或shell/bat存在的问题，首先，有很多配置需要你填写，源码目录，字节码目录……，每一个项目，你都要重复这些劳动；第二，也是更重要的一点，你根本无法保证N个项目的ant配置（或shell）配置使用了相同的风格，后果是，每接受一个项目，开发者都要去学习这份脚本，以了解如何构建项目。如果第一个原因只是为了技术的简化的话，第二个原因更是软件工程的因素，我们不是一个人在开发项目，不是只开发一个项目，所以应该时刻谨记为了别人，为了将来。

 

现在看看使用Maven我们需要什么配置，就一个pom.xml文件：

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.sonatype.mavenbook</groupId>
  <artifactId>my-project</artifactId>
  <version>1.0</version>
</project>

不用惊讶，Maven不会变魔术，它能做到这么简单，是有条件的，条件就是你要遵守Maven约定。pom.xml所在的目录应为项目的根目录，假设该目录为${proj-dir}，那么Maven有以下假设：

• ${proj-dir}/src/main/java —— 存放项目的.java文件。
  
• ${proj-dir}/src/main/resources —— 存放项目资源文件，如spring, hibernate配置文件。
  
• ${proj-dir}/src/test/jave —— 存放所有测试.java文件，如JUnit测试类。
  
• ${proj-dir}/src/test/resources —— 测试资源文件。
  
• ${proj-dir}/target —— 项目输出位置。
  

运行一条mvn clean package命令，Maven会帮你清除target目录，重新建一个空的，编译src/main/java类至target/classes，复制src/main/resources的文件至target/classes，编译src/test/java至target/test-classes，复制src/test/resources的文件至target/test-classes；然后运行所有测试；测试通过后，使用jar命令打包，存储于target目录。Maven做的事情一点也不少，只是都对用户隐蔽起来了，它只要求你遵循它的约定。

 

这么做有什么好处呢？第一，显而易见，配置大量减少了，随着项目变得越复杂，这种优势就越明显。第二，我这里要强调的是，对于软件工程来说，所有使用Maven的项目，对外都暴露统一的命令集。如mvn clean install。只要项目被正确配置好了，任何一个新人，输入一行Maven命令，就能将项目构建起来了，这大大减少了交流学习的时间。

 

这时可能会有人说，我不想遵守这种约定呢？我要把源码放在${proj-dir}/src/code目录下。首先，问自己三遍，你真的需要这样做么？如果仅仅是因为喜好，那么别耍个性，个性意味着牺牲通用性，意味着增加无谓的复杂度。以下是一个“个性”的例子：

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.sonatype.mavenbook</groupId>
  <artifactId>my-project</artifactId>
  <version>1.0</version>
  <build>
    <sourceDirectory>src/java</sourceDirectory>
    <testSourceDirectory>src/test</testSourceDirectory>
    <outputDirectory>output/classes</outputDirectory>
    <testOutputDirectory>output/test-classes</testOutputDirectory>
    <directory>target/jar</directory>
  </build>
</project>

很显然，Maven允许你自定义，比如这个例子中，Maven就被配置成从src/java目录寻找源码，编译class文件至output/classes，从src/test寻找测试源码，编译至output/test-classes目录，最后，打包jar文件至target/jar目录。Maven允许你这么做，但不推荐你这么做。因为一旦你使用这种自定义，习惯Maven约定的人一开始会觉得奇怪，src/main/java目录去哪里了？target下面怎么没有我要的jar文件？这些都造成了无谓的交流成本提高。只有一些特殊的情况，这些自定义手段能帮你解决实际的问题，比如你在处理遗留代码，你没办法改变源码目录结构，这个时候只有让Maven妥协。

 

下面总结一些Maven的默认值，也就是说，虽然你没做什么配置，但是你应该知道Maven假设它们成立，也就是所谓的“约定”：

Maven约定

目录src/main/java	java源码目录
目录src/main/resources	资源文件目录
目录src/test/java	测试java源码目录
目录src/test/resources	测试资源文件目录
目录target	打包输出目录
目录target/classes	编译输出目录
目录target/test-classes	测试编译输出目录
目录target/site	项目site输出目录
目录src/main/webapp	web应用文件目录（当打包为war时），如WEB-INF/web.xml
jar	默认打包格式
*Test.java	Maven只会自动运行符合该命名规则的测试类
%user_home%/.m2	Maven默认的本地仓库目录位置
中央仓库	Maven默认使用远程中央仓库：http://repo1.maven.org/maven2
1.3	Maven Compiler插件默认以1.3编译，因此需要额外配置支持1.5

 

其实基本上所有的约定，或者说默认配置，都可以在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的时候，你应该尽可能遵循它的配置约定，一方面可以简化配置，另一方面可建立起一种标准，减少交流学习成本。一旦你习惯了这种约定，你得到的回报是巨大的。反之，恣意的做自定义，想要Maven像Ant一样听你的话，那么你会讨厌Maven，Maven也会讨厌你。

评论

5 楼 smartdog 2017-02-06  

言简意赅，厉害

4 楼 guanpb 2015-06-09  

好文章，很受用

3 楼 shooray 2009-05-26  

看【约定】就知道应该是原创，顶作者。

规约这个词不知道是谁创造出来的，听着都难受。现有的词汇可以表达的东西，就不要再发明创造了。

2 楼 shiren1118 2008-12-15  

可以达意，感觉还是像翻译的，嘎嘎~~~

1 楼 shiren1118 2008-12-15  

约定优于配置（Convention Over Configuration）

叫规约的也挺多的~~~~