BlogJava-Jiangshachina-随笔分类-Build

使用Gradle构建Java Web应用(译)

Sha Jiang — Thu, 23 Jan 2014 13:22:00 GMT

使用Gradle构建Java Web应用

本文是发布在java.net上的一篇摘自于一书中的节选，介绍了使用Gradle构建Java Web应用的过程。刚刚接触Gradle，看到了这篇小文，随手译了出来:-) (2014.01.23最后更新)

当今世界，一派繁忙。在职业生涯和私人生活中，我们中间的许多人要同时管理多个项目。你可能常常发现自己处于不知所措及失控的状态。保持规整并专注于价值的关键是一个维护良好的工作清单。当然，你可能总是把你的任务写在一张纸上，但是你也许不可能在你所处的任何地方都可方便地获得这些工作条目？对互联网的访问几乎是无处不在的，无论是通过你的移动电话，还是公共的网络接入点。在一书中，如图1所示的说明性示例是一个很有吸引力的可视化Web应用。

图1 To Do应用可以通过互联网进行访问，并使用它去管理数据存储中的工作条目

Gradle插件表现的如同一个使能器，它会自动地执行这些任务。一个插件通过引入特定领域的规范以及对缺省值敏感的任务去对工程进行扩展。随Gradle发布的插件之一就是Java插件。该Java插件绝不仅仅是提供了源码编译和打包这样的基础功能。它为工程建立了一整套标准的目录布局，它会确保以正确的顺序去执行任务，这样，这些任务在Java工程环境中才是有意义的。现在是时候为我们的应用去创建一个构建脚本并去使用这个Java插件了。

构建Java应用
一开始，每个Gradle工程都会创建一个名为build.gradle的构建脚本。为了创建该脚本，并告诉该工程使用Java插件，应该像这样去做：

apply plugin: 'java'

为了构建你的Java代码，一行代码就够了。但Gradle怎么知道去哪儿找你的源文件呢？该Java插件引入的规范之一就是源代码的路径。默认地，该插件会到目录src/main/java中搜寻产品的源代码。

构建Web应用
通过War插件，Gradle也提供了构建Web应用的扩展支持。War插件扩展了Java插件，它加入了针对Web应用程序开发的规范，并支持归集WAR文件。让我们也在这个工程中用用War插件：

apply plugin: 'war'

Web应用源文件的默认路径是src/main/webapp。假设你已经明确了该应用所必要的Java类。那么要使产品的全部源代码和Web资源文件处于正确路径下，该工程的目录布局应该像下面这样：

.
├── build.gradle
└── src
    └── main
        ├── java
        │   └── com
        │       └── manning
        │           └── gia
        │               └── todo
        │                   ├── model
        │                   │   └── ToDoItem.java
        │                   ├── repository
        │                   │   ├── InMemoryToDoRepository.java
        │                   │   └── ToDoRepository.java
        │                   └── web
        │                       └── ToDoServlet.java
        └── webapp                                               #A
            ├── WEB-INF
            │   └── web.xml                                      #B
            ├── css                                              #C
            │   ├── base.css
            │   └── bg.png
            └── jsp                                              #D
                ├── index.jsp
                └── todo-list.jsp

#A Web源文件默认目录
#B Web应用描述符文件
#C 存储描述如何展现HTML元素的样式单文件的目录
#D 存放JSP形式的动态脚本化视图组件

声明外部依赖
在实现这个Web应用的过程，我们使用的一些类，例如javax.servlet.HttpServlet，并非Java标准版(Java SE)的一部分。在构建工程之前，我们需要确保已经声明了这些外部依赖。在Java系统中，依赖类库是以JAR文件的形式去发布和使用的。许多类库可以从仓库，如一个文件系统或中央服务器，中获得。为了使用依赖，Gradle要求你至少定义一个仓库。出于一些考虑，我们将使用公共的可通过互联网进行访问的Maven Central仓库。

repositories {
mavenCentral() #A
}
#A 通过http://repo1.maven.org/maven2访问Maven2中央仓库的简短标记

在Gradle中，依赖是通过配置项来进行分组的。我们将来Servlet依赖使用的配置项是providedCompile。该配置项用于那些在编译时而非运行时所需的依赖。像JSTL这样的运行时依赖，在编译时不会被用到，但在运行时则会被用到。它们都会成为WAR文件的一部分。下面的配置语句块声明了我们应用所需的外部类库：

dependencies {
providedCompile 'javax.servlet:servlet-api:2.5'
runtime 'javax.servlet:jstl:1.1.2'
}

构建工程
我们已经准备好构建这个工程了。另到工程中的一个Java插件任务名为build。该任务将编译源代码，运行测试程序并归集WAR文件--所有的这些任务都将以正确的顺序被执行。执行命令gradle build之后，你可能会得到形如下面的输出：

$ gradle build
:compileJava                                      #A
:processResources UP-TO-DATE
:classes
:war                                              #B
:assemble
:compileTestJava UP-TO-DATE                       #C
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test                                             #D
:check
:build

#A 编译产品的Java源代码
#B War插件提供的任务，用于归集WAR文件
#C 编译Java测试源代码
#D 运行单元测试

上述输出的每一行都代表执行了一个由Java或War插件提供的任务。你可能会注意到，有一些任务被标记为UP-TO-DATE。它的意思是指该任务被跳过去了。Gradle的增量构建支持策略会自动识别不需要执行的工作。特别是在大型商业项目中，该特性会极大地节省时间。
在该工程的根节目录中，你将会发现一个名为build的子目录，它包含有执行构建之后的全部输出，包括类文件，测试报告，归集的WAR文件，以及像manifest这样的在打包时需要的临时文件。如下就是执行构建工作之后的工程目录结构：

.
├── build
│   ├── classes
│   │   └── main                                          #A
│   │       └── com
│   │           └── manning
│   │               └── gia
│   │                   └── todo
│   │                       ├── model
│   │                       │   └── ToDoItem.class
│   │                       ├── repository
│   │                       │   ├── InMemoryToDoRepository.class
│   │                       │   └── ToDoRepository.class
│   │                       └── web
│   │                           ├── ToDoServlet$ToDoListStats.class
│   │                           └── ToDoServlet.class
│   ├── dependency-cache
│   ├── libs
│   │   └── todo-webapp.war                               #B
│   ├── reports
│   │   └── tests
│   │       ├── base-style.css
│   │       ├── css3-pie-1.0beta3.htc
│   │       ├── index.html
│   │       ├── report.js
│   │       └── style.css
│   ├── test-results
│   │   └── binary
│   │       └── test
│   │           └── results.bin
│   └── tmp
│       └── war
│           └── MANIFEST.MF                                #C
├── build.gradle
└── src

#A 包含Java类文件的默认目录
#B 归集的WAR文件
#C 用于WAR的临时manifest文件

你已经知道如何从一个基于标准目录结构的Web工程去构建WAR文件。现在是时候将它布署到一个Servlet容器中去了。在下一节中，我们将在本地开发机器中启动Jetty去运行这个Web应用。

运行应用
在本地机器中运行一个Web应用应该很容易，能够实践快速应用开发(RAD)，并能够提供快速的启动时间。最棒地是，它不要求你部署一个Web容器运行时环境。Jetty一个流行的轻量级开源Web容器，它支持前面提到的所有特性。在这个Web应用中加入一个HTTP模块，它就变成了一个嵌入式实现。Gradle的Jetty插件扩展了War插件，它提供的任务可以将一个Web应用部署到嵌入式容器中，并能够启动该应用。在你的构建脚本中，可以像如下那样使用这个插件：

apply plugin: 'jetty'

这个将被我们用于启动Web应用的任务名为jettyRun。它甚至可以在无需创建WAR文件的情况下启动一个Jetty容器。执行上述命令后会得到如下形式的输出：

$ gradle jettyRun
:compileJava
:processResources UP-TO-DATE
:classes
> Building > :jettyRun > Running at http://localhost:8080/todo-webapp-jetty

在上述输出的最后一行中，该插件告诉了你Jetty即将侦听的请求地址。打开一个你喜欢的浏览器，并输入上述地址。最后，我们会看到这个To Do Web应用的行为。图2展示在一个浏览器中查看到该应用界面的截屏。

图2 To Do应用的Web界面及其行为

在你通过组合键CTRL+C去停止这个应用之前，Gradle会让它一直运行。Jetty如何知道使用哪个端口和上下文环境去运行这个Web应用？再说一遍，这就是规范。Jetty运行Web应用所使用的默认端口就是8080。

总结
只需要较少的努力，你就可以使用Gradle去构建并运行一个Java Web应用。只要你严格遵循标准目录结构，那么你的构建脚本仅需要两行代码。

Sha Jiang 2014-01-23 21:22 发表评论

最大限度利用Maven settings.xml文件(译)

Sha Jiang — Fri, 14 Aug 2009 11:13:00 GMT

最大限度利用Maven settings.xml文件

John Ferguson在他的最新Blog中，介绍了使用Maven settings.xml文件的一些鲜为人知的技巧，希望对大家也有所助益。(2009.08.14最后更新)

如果你在任何程度中使用过Maven，你应该知道settings.xml文件。settings.xml文件包含有与系统环境相关的配置细节，例如代理配置，仓库，服务器的用户名和密码，等等。
下面是一个典型的settings.xml文件的示例：

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                      http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <localRepository>C:/maven/repositorylocalRepository>

  <proxies>
    <proxy>
      <id>localproxyid>
      <active>trueactive>
      <protocol>httpprotocol>
      <host>proxy.acme.comhost>
      <port>8080port>
      <username>scottusername>
      <password>t0ps3cr3tpassword>
      <nonProxyHosts>*.acme.comnonProxyHosts>
    proxy>
  proxies>

  <servers>
    <server>
      <id>dbserverid>
      <username>scottusername>
      <password>tigerpassword>
    server>
  servers>

settings>

例如，若你使用公司的环境，在该环境中，你的Maven主目录是每天早晨当你登录时由网络传输的，localRepository元素就会非常有用。在这种情况下，将本地仓库置于你本地磁盘的不同目录中，将会节约大量的带宽。
你也可以在settings.xml文件中定义仓库，镜像，概述和属性。在此处，我不想涉及上述内容，因为在其它地方已经有关于它们的很好的文档了。
很少为人所知，或至少是很少被使用的功能是，在你的pom.xml文件中使用定义在settings.xml文件中的数据。事实上，你能使用settings.xml中的任一元素，然而其中的一些则更为有用。
一个普遍且方便的例子就是使用localRepository变量。你可能需要将该变量置于一个脚本中，或使用它来引用仓库中的某个特定的JAR文件(尽管通常有更优雅的方案来解决这一问题)。你可以通过简单地引用${settings.localRepository}来使用localRepository属性。例如，在下面的代码中，我们调用一个Ant脚本，并通过名为"localRepository"的属性传给它一个本地仓库路径：

<plugin>
  <groupId>org.apache.maven.pluginsgroupId>
  <artifactId>maven-antrun-pluginartifactId>
  <executions>
    <execution>
      <id>generate-stuffid>
      <phase>pre-comilephase>
      <goals>
        <goal>rungoal>
      goals>
      <configuration>
        <tasks>
          <ant target="generate">
            <property name="localRepository"  value="${settings.localRepository}"/>
          ant>
        tasks>
      configuration>
    execution>
  executions>
plugin>

做更多有趣的事情，特别是当你也在构建中集成了Groovy时。例如，假设在集成测试阶段期间，我们需要确保特定的SQL脚本已在数据库中执行过了。我们有一个名为update-scripts.groovy的Groovy脚本来做这件事情，但它需要以命令行参数的形式提供用户名和密码。在集成测试阶段之前，你应如何使用定义在settings.xml中的用户名和密码呢？是的，只需一点儿Groovy魔术，没有比这儿更简单的了。settings对象可用于任何集成到pom.xml中的Groovy脚本，所以你可像使用一个普通对象那样方便地使用它，如下示例：

<plugin>
  <groupId>org.codehaus.groovy.mavengroupId>
  <artifactId>gmaven-pluginartifactId>
  <version>1.0-rc-5version>
  <executions>
    <execution>
      <id>process-db-scriptsid>
      <phase>pre-integration-testphase>
      <goals>
        <goal>executegoal>
      goals>
      <configuration>
        <source>
        def server = settings.servers.find{ it.id.equals('dbserver') }
        """groovy update-scripts.groovy -Ddb.username=${server.username}
        -Ddb.password=${server.password}""".execute()
        source>
      configuration>
    execution>
  executions>
plugin>

简单！事实上，一旦你既知道如何访问顶级变量，又知道如何访问settings.xml中的各个元素，那么其功效将不可限量！只需记住一定要使你的构建保持弹性--例如，不要在settings.xml文件中定义那些在pom.xml文件中无有效默认值的属性。
如果你想学习更多关于应用Maven的酷炫方法，查看最新的来自于Sonatype的在线课程。或者，为了有一个更具全景的视角，可以参加Java Power Tools bootcamp会议--很快在堪培拉，悉尼，布里斯班和惠灵顿就有研讨会了。

Sha Jiang 2009-08-14 19:13 发表评论

出错时的软件开发(译)

Sha Jiang — Mon, 27 Oct 2008 00:44:00 GMT

出错时的软件开发

在开发的过程中有错误发生了，此时你该如何应对呢？John Ferguson Smart在他的最新博客中提出了一些想法，大家可以参考一下(2008.10.27最后更新)

    现今比以后任何时候，都需要开发者更加高效。极度高效。组织需要提高从它们的开发项目中得到的附加值，并且它们也乐于寻找实现这一目标的方法。
当然，你可以采用传统的方法--努力工作。为了消除项目中不可预见的症状，每天工作16个小时，还没有周末。但做的更聪明一点儿，会不会更好些？
在引进新的实践方法及改进现有方法方面投入的相对多一些，以使组织能努力获得更多回报，这就是开发的过程。一般而言，事物中有许多方面都可以被改进，但此处有一些小窍门能使你的开发流程更加合理，只是为你开个头罢了。

持续集成(CI)通知策略的再思考
    到目前为止，最通用的CI通知机制就是陈旧的邮件服务器。然而，你能肯定在你手边能完成这项任务的最合适系统就是电子邮件吗？尝试不使用电子邮件，而使用即时消息去完成你的CI通知。记住，电子邮件易成为一种干扰--如果你仅仅大约每两小时才查阅一次邮件，你就会变得十分高效。电子邮件只是，或至少是，用于构建失败--人们需要快速地知晓失败任务。

积极地优化构建过程
    构建度量(Build Metrics)是一种监控构建过程健康状况的极好方法。为什么过去3周中，代码覆盖率一直在下降？为什么单元测试的数量并未呈有规律的增长？为什么要花费很长的时间去修复这样的构建？运行单元测试需要多长时间--是否有一些测试需要执行过分长的时间？这些信息并非华而不实的东西--在不断改进构建过程的工作中，它们都扮演着关键的角色。现代CI工具，如Hudson，Bamboo和TeamCity，能为构建展示丰富的统计。Bamboo在这方面做的尤佳。无论你正使用何种CI工具，都要学习如何最大限度地使用它的报表特性，并使用这些特性去定位及修复开发过程中讨厌污点。如果你的CI工具不能给你所需要的全部信息，那就找一个能做到的。

合理化发布过程
    在发布过程中有许多必做的工作，如准备发行说明，确定该版本中哪些问题已被解决了，标记版本，等等。这些都是软件生命周期的重要部分，如果你忽略了它们，QA们和最终用户可能会很生气。但要尽量自动地去做这些工作。许多CI工具能很好地与问题追踪系统(如JIRA和Trac)进行集成，以便你能基于版本控制日志看到某个问题是在哪次特定的构建中被解决的。如果你在使用Eclipse，Mylyn能帮你将处理过的问题归总成逻辑变化组，并使用标准的模板列出在某项工作中已被解决的(或仅是影响到的)问题。或者你可使用Subversion的hook脚本去确保每次向Subversion做的提交都能对应到一个有效的问题编号。
    这只是一些想法罢了--还有更多。底线就是--你不需要忍耐一个次理想的开发过程--相反，要进入其中，并做些能改进它的事情。祝好运!

Sha Jiang 2008-10-27 08:44 发表评论