Java构建工具对比

Java构建工具对比

Linux C开发中我们常常使用Make进行构建,不过Make将自己和操作系统绑定在一起了;也就是说,使用Make,就不能实现(至少很难)跨平台的构建,这对于Java来说是非常不友好的。此外,Makefile的语法也成问题,很多人抱怨Make构建失败的原因往往是一个难以发现的空格或Tab使用错误。而在Java发展过程中常见的自动化构建工具以Ant、Maven、Gradle为代表,整个自动化流程往往包含以下步骤:编译源代码、运行单元测试和集成测试、执行静态代码分析、生成分析报告、创建发布版本、部署到目标环境、部署传递过程以及执行冒烟测试和自动功能测试。

Make一样,Ant也都是过程式的,开发者显式地指定每一个目标,以及完成该目标所需要执行的任务。针对每一个项目,开发者都需要重新编写这一过程,这里其实隐含着很大的重复。Maven是声明式的,项目构建过程和过程各个阶段所需的工作都由插件实现,并且大部分插件都是现成的,开发者只需要声明项目的基本元素,Maven就执行内置的、完整的构建过程。这在很大程度上消除了重复。

此外,Ant是没有依赖管理的,所以很长一段时间Ant用户都不得不手工管理依赖,这是一个令人头疼的问题。幸运的是,Ant用户现在可以借助Ivy管理依赖。而对于Maven用户来说,依赖管理是理所当然的,Maven不仅内置了依赖管理,更有一个可能拥有全世界最多Java开源软件包的中央仓库,Maven用户无须进行任何配置就可以直接享用。

Gradle抛弃了Maven的基于XML的繁琐配置;众所周知XML的阅读体验比较差,对于机器来说虽然容易识别,但毕竟是由人去维护的。取而代之的是Gradle采用了领域特定语言Groovy的配置,大大简化了构建代码的行数。Maven的设计核心Convention Over ConfigurationGradle更加发扬光大,而Gradle的配置即代码又超越了Maven。在Gradle中任何配置都可以作为代码被执行的,我们也可以随时使用已有的Ant脚本(Ant taskGradle中的一等公民)Java类库、Groovy类库来辅助完成构建任务的编写。在《Java-Notes》系列文章中也有专门的章节讲解Gradle,笔者在AndroidSpring项目构建中也会优先选择Gradle

Ant with Ivy

Ant是第一个“现代”构建工具,在很多方面它有些像Make2000年发布,在很短时间内成为Java项目上最流行的构建工具。它的学习曲线很缓,因此不需要什么特殊的准备就能上手。它基于过程式编程的idea。在最初的版本之后,逐渐具备了支持插件的功能。主要的不足是用XML作为脚本编写格式。XML,本质上是层次化的,并不能很好地贴合Ant过程化编程的初衷。Ant的另外一个问题是,除非是很小的项目,否则它的XML文件很快就大得无法管理。后来,随着通过网络进行依赖管理成为必备功能,Ant采用了Apache Ivy

Ant的主要优点在于对构建过程的控制上。Ivy的依赖需要在ivy.xml中指定。我们的例子很简单,只需要依赖JUnitHamcrest

<ivy-module version="2.0">
    <info organisation="org.apache" module="java-build-tools"/>
    <dependencies>
        <dependency org="junit" name="junit" rev="4.11"/>
        <dependency org="org.hamcrest" name="hamcrest-all" rev="1.3"/>
    </dependencies>
</ivy-module>

现在我们来创建Ant脚本,任务只是编译一个Jar文件。最终文件是下面的build.xml

<project xmlns:ivy="antlib:org.apache.ivy.ant" name="java-build-tools" default="jar">

    <property name="src.dir" value="src"/>
    <property name="build.dir" value="build"/>
    <property name="classes.dir" value="${build.dir}/classes"/>
    <property name="jar.dir" value="${build.dir}/jar"/>
    <property name="lib.dir" value="lib" />
    <path id="lib.path.id">
        <fileset dir="${lib.dir}" />
    </path>

    <target name="resolve">
        <ivy:retrieve />
    </target>

    <target name="clean">
        <delete dir="${build.dir}"/>
    </target>

    <target name="compile" depends="resolve">
        <mkdir dir="${classes.dir}"/>
        <javac srcdir="${src.dir}" destdir="${classes.dir}" classpathref="lib.path.id"/>
    </target>

    <target name="jar" depends="compile">
        <mkdir dir="${jar.dir}"/>
        <jar destfile="${jar.dir}/${ant.project.name}.jar" basedir="${classes.dir}"/>
    </target>

</project>

首先,我们设置了几个属性,然后是一个接一个的task。我们用Ivy来处理依赖,清理,编译和打包,这是几乎所有的Java项目都会进行的task,配置有很多。

运行Ant task来生成Jar文件,执行下面的命令。

ant jar

Maven

Maven发布于2004年。目的是解决码农使用Ant所带来的一些问题。Maven仍旧使用XML作为编写构建配置的文件格式,但是,文件结构却有巨大的变化。Ant需要码农将执行task所需的全部命令都一一列出,然而Maven依靠约定(convention)并提供现成的可调用的目标(goal)。不仅如此,有可能最重要的一个补充是,Maven具备从网络上自动下载依赖的能力(Ant后来通过Ivy也具备了这个功能),这一点革命性地改变了我们开发软件的方式。

但是,Maven也有它的问题。依赖管理不能很好地处理相同库文件不同版本之间的冲突(Ivy在这方面更好一些)XML作为配置文件的格式有严格的结构层次和标准,定制化目标(goal)很困难。因为Maven主要聚焦于依赖管理,实际上用Maven很难写出复杂、定制化的构建脚本,甚至不如Ant。用XML写的配置文件会变得越来越大,越来越笨重。在大型项目中,它经常什么“特别的”事还没干就有几百行代码。

Maven的主要优点是生命周期。只要项目基于一定之规,它的整个生命周期都能够轻松搞定,代价是牺牲了灵活性。在对DSL(Domain Specific Languages)的热情持续高涨之时,通常的想法是设计一套能够解决特定领域问题的语言。在构建这方面,DSL的一个成功案例就是Gradle

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

http://maven.apache.org/maven-v4_0_0.xsd">

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.technologyconversations</groupId>
    <artifactId>java-build-tools</artifactId>
    <packaging>jar</packaging>
    <version>1.0</version>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.11</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.3.2</version>
            </plugin>
        </plugins>
    </build>

</project>

通过执行下面的命令来运行Maven goal生成Jar文件。

mvn package

主要的区别在于Maven不需要指定执行的操作。我们没有创建task,而是设置了一些参数(有哪些依赖,用哪些插件…). Maven推行使用约定并提供了开箱即用的goalsAntMavenXML文件都会随时间而变大,为了说明这一点,我们加入CheckStyleFindBugsPMD插件来进行静态检查,三者是Java项目中使用很普遍的的工具。我们希望将所有静态检查的执行以及单元测试一起作为一个单独的targetVerify。当然我们还应该指定自定义的checkstyle配置文件的路径并且确保错误时能够提示。更新后的Maven代码如下:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-checkstyle-plugin</artifactId>
    <version>2.12.1</version>
    <executions>
        <execution>
            <configuration>
                <configLocation>config/checkstyle/checkstyle.xml</configLocation>
                <consoleOutput>true</consoleOutput>
                <failsOnError>true</failsOnError>
            </configuration>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>findbugs-maven-plugin</artifactId>
    <version>2.5.4</version>
    <executions>
        <execution>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-pmd-plugin</artifactId>
    <version>3.1</version>
    <executions>
        <execution>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

通过执行下面的命令来运行Maven goal,包括单元测试,静态检查,如CheckStyleFindBugsPMD

mvn verify

Gradle

Gradle结合了前两者的优点,在此基础之上做了很多改进。它具有Ant的强大和灵活,又有Maven的生命周期管理且易于使用。最终结果就是一个工具在2012年华丽诞生并且很快地获得了广泛关注。例如,Google采用Gradle作为Android OS的默认构建工具。Gradle不用XML,它使用基于Groovy的专门的DSL,从而使Gradle构建脚本变得比用AntMaven写的要简洁清晰。Gradle样板文件的代码很少,这是因为它的DSL被设计用于解决特定的问题:贯穿软件的生命周期,从编译,到静态检查,到测试,直到打包和部署。

它使用Apache Ivy来处理Jar包的依赖。Gradle的成就可以概括为:约定好,灵活性也高。

apply plugin: 'java'
apply plugin: 'checkstyle'
apply plugin: 'findbugs'
apply plugin: 'pmd'

version = '1.0'

repositories {
    mavenCentral()
}

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.11'
    testCompile group: 'org.hamcrest', name: 'hamcrest-all', version: '1.3'
}