vlambda博客
学习文章列表

让我们将项目的根目录创建为hello-web。该结构类似于我们在一个简单的 Java 应用程序中看到的结构，只是增加了一个，即 Web 应用程序根。默认情况下，Web 应用程序根位于 src/main/webapp。熟悉 Maven 的人会立即注意到，这与 Maven 使用的路径相同。

Web 应用程序根 (webapp) 包含运行 Web 应用程序所需的所有公共资源，其中包括 JSP 等动态页面或其他视图模板所需的文件 Thymeleaf、FreeMarker、Velocity等引擎；以及静态资源，例如 HTML、CSS、JavaScript 和图像文件；和其他配置文件，如 web.xml 在名为 WEB-INF 的特殊目录中。 WEB-INF 中存储的文件不能被客户端直接访问；因此，它是存储受保护文件的理想场所。

我们将从创建最终应用程序的目录结构开始：

hello-web
├── build.gradle
└── src
    └── main
        ├── java// source root
        │ └── com
        │     └── packtpub
        │         └── ge
        │             └── hello
        │                 ├── GreetingService.java
        │                 └── GreetingServlet.java
        └── webapp// web-app root
            ├── WEB-INF
            │ └── greet.jsp
            └── index.html

然后，执行以下步骤：

最后，让我们在项目的根：

apply plugin: 'war'

repositories {
    mavenCentral()
}

dependencies {
    providedCompile 'javax.servlet:javax.servlet-api:3.1.0'
}

现在让我们尝试理解这个文件：

最后，在 dependencies 块中，我们添加 servlet-api< /code> 到 providedCompile 配置（范围）。这告诉 Gradle 不要将 servlet API 与应用程序打包在一起，因为它已经在部署应用程序的容器上可用。 providedCompile 配置由 war 插件添加（它还添加了 providedRuntime ）。如果我们有任何其他依赖项需要与我们的应用程序一起打包，它会使用编译配置声明。例如，如果我们的应用程序依赖于 Spring 框架，那么依赖项部分可能如下所示：

dependencies {
    compile 'org.springframework:spring-context:4.0.6.RELEASE'
    providedCompile 'javax.servlet:javax.servlet-api:3.1.0'
}

如果感觉像 repositories、configurations 和 dependencies 的详细信息，请不要担心代码>有点粗略。我们很快将在本章后面更详细地再次看到它们。

现在我们的源文件已经准备好构建文件，我们必须构建可部署的WAR文件。让我们使用以下命令验证可用于我们的构建的任务：

$ gradle tasks --all
…
war - Generates a war archive with all the compiled classes, the web-app content and the libraries. [classes]
…

我们会注意到那里的 war 任务，它依赖于 classes （任务）。我们不需要显式编译和构建 Java 源代码，这由 classes 任务自动处理。所以我们现在需要做的就是，使用以下命令：

$ gradle war

构建完成后，我们将看到目录结构类似于以下结构：

hello-web
├── build
│ ├── classes
│ │ └── main
│ │     └── com
│ │         └── packtpub
│ │             └── ge
│ │                 └── hello
│ │                     ├── GreetService.class
│ │                     └── GreetServlet.class
│ ├── dependency-cache
│ ├── libs
│ │ └── hello-web.war
│ └── tmp
│     └── war
│         └── MANIFEST.MF
…

战争文件 在 /build/libs/hello-web.war 创建。

让我们检查一下这个 WAR 文件的内容：

…

├── META-INF
│ └── MANIFEST.MF
├── WEB-INF
│ ├── classes
│ │ └── com
│ │     └── packtpub
│ │         └── ge
│ │             └── hello
│ │                 ├── GreetService.class
│ │                 └── GreetServlet.class
│ └── greet.jsp
└── index.html

完美的。编译后的类进入 WEB-INF/classes 目录。 servlet API 的 JAR 不包含在 providedCompile 范围内。

在创建网络应用方面取得了长足的进步。但是，要使用它，必须将其部署到 servlet 容器。可以通过复制servlet容器指定目录下的.war文件（如webapps中的.war文件经典部署到servlet容器中Tomcat 的情况）。或者，可以使用更新的技术将 Servlet 容器嵌入到 Java 应用程序中，该应用程序被打包为 .jar 并像任何其他 java –jar 命令。

Web 应用程序通常以三种模式运行，开发、功能测试和生产。这三种模式的主要特点不同如下：

我们将仅介绍本章中的开发场景。我们将从传统的方式开始突出它的问题，然后转向 Gradle 的方式。

现在，如果我们需要手动部署战争。我们可以选择任何 Java servlet 容器，例如 Jetty 或 Tomcat 来运行我们的 Web 应用程序。在这个例子中，让我们使用 Tomcat。假设 Tomcat 安装在 ~/tomcat 或 C:\tomcat （基于我们使用的操作系统）：

然而，这种部署在 Gradle 时代已经过时了。尤其是在开发 web-app的时候，我们要不断的把应用打包成war，复制容器的最新版本，然后重新启动容器以运行最新的代码。当我们说构建自动化时，它隐含地意味着不应该期望人工干预并且事情应该一键运行（或者在 Gradle 的情况下是一个命令）。此外，幸运的是，有很多选择可以实现这种自动化水平。

Plugins to the rescue

开箱即用，Gradle 不支持现代 servlet 容器。然而，这正是 Gradle 架构的美妙之处。创新和/或实施不一定来自创建 Gradle 的少数人。在插件 API 的帮助下，任何人都可以创建功能丰富的插件。我们将使用一个名为 Gretty 的插件来部署我们的 web 应用程序的开发时间，但您还应该查看其他插件以了解最适合您的插件。

Note

Gradle 附带了一个 jetty 插件。但是，它并没有积极更新；因此，它官方只支持 Jetty 6.x（在撰写本文时）。因此，如果我们的 Web 应用程序基于 Servlet 2.5 或更低的规范，我们就可以使用它。

可以在 Gradle 插件门户中找到 Gretty 插件（查看下面的参考资料）。该插件为构建添加了许多任务，并支持各种版本的 Tomcat 和 Jetty。安装它再简单不过了。此代码使用与上一节相同的 hello-web 源代码，但更新了 build.gradle 文件。该示例的完整源代码可以在本书示例代码的chapter-03/hello-gretty 目录中找到。

只需在 build.gradle 的第一行包含以下内容：

plugins {
  id "org.akhikhl.gretty" version "1.2.4"
}

Copy

就是这样——我们完成了。这是在 Gradle 2.1 中添加的用于将插件应用于构建的相对较新的语法。这对于应用第三方插件特别有用。与调用 apply 方法来应用插件不同，我们从第一行的插件块开始。然后，我们指定插件的 ID。要应用外部插件，我们必须使用完全限定的插件 ID 和版本。我们可以在这个块中包含 war 插件的应用程序。对于内部插件，我们不需要指定版本。它将如下所示：

plugins {
  id "org.akhikhl.gretty" version "1.2.4"
  id "war"
}

Copy

如果我们现在运行 gradle tasks，我们必须在 Gretty appRun 任务代码>组。这个组还有很多任务，都是 Gretty 插件添加的。如果我们运行 appRun 任务，而不显式配置插件，那么默认情况下，Jetty 9 将在 http://localhot:8080 上运行 。我们可以打开浏览器进行验证。

插件公开了许多配置，用于控制服务器版本、端口号等方面。在 build.gradle 文件中添加 gretty 块，如下所示:

• 如果我们想在端口 8080 上使用 Tomcat 8，我们将添加以下代码行：

  gretty {
    servletContainer = 'tomcat8'
    port = 8080
  }

  Copy

• 如果我们想在 9080 上使用 Jetty 9，我们将添加以下代码行：

  gretty {
    servletContainer = 'jetty9'
    port = 9080
  }

  Copy

Gretty 中还有更多可用的配置选项；我们建议您查看 Gretty 的在线文档。请参阅参考资料部分中的 Gretty 链接。

以下是正在运行的应用程序的外观：

一旦 提交按钮被按下，我们将得到以下结果：

几乎 所有现实世界的项目都依赖于外部库 来重用经过验证和测试的成分。此类依赖项包括语言实用程序、数据库驱动程序、Web 框架、XML/JSON 序列化库、ORM、日志实用程序等等。

项目的依赖关系在构建文件的 dependencies 部分中声明。

Gradle 提供了一种非常简洁的语法来声明工件的坐标。它通常采用 group:name:version 的形式。请注意，每个值都用冒号分隔（:）。

例如，可以使用以下代码引用 Spring Framework 的核心库：

dependencies {
  compile 'org.springframework:spring-core:4.0.6.RELEASE'
}

compile group:'org.springframework', name:'spring-core', version:'4.0.6.RELEASE'

我们还可以指定多个依赖项，如下所示：

configurationName dep1, dep2, dep3…. 

其中configurationName代表compile、testCompile等配置，我们很快就会看到在这种情况下是什么配置。

runtime 'org.slf4j:slf4j-nop:1.7+'

$ gradle dependencies
…
+--- org.slf4j:slf4j-nop:1.7+ -> 1.7.7
|    \--- org.slf4j:slf4j-api:1.7.7
…

    runtime ('org.slf4j:slf4j-nop:1.7+') {
        transitive = false
    }

\--- org.slf4j:slf4j-nop:1.7.2

    runtime ('org.slf4j:slf4j-nop:1.7.2') {
        force = true  
    }

+--- org.slf4j:slf4j-api:1.7.2
\--- org.slf4j:slf4j-nop:1.7.7
     \--- org.slf4j:slf4j-api:1.7.7 -> 1.7.2

Gradle 提供了一种非常优雅的方式来声明构建不同组所需的依赖项项目构建的各个阶段的资源。

正如我们在一个源集中定义了相关源的组，依赖关系也被定义为一个称为 的组配置。每个配置都有其名称，例如 compile、testCompile 等。各种配置中包含的依赖关系也不同。配置按依赖项的特征分组。例如，以下是 java 和 war 插件添加的配置：

我们知道，当我们应用war插件时，java 插件也被应用。这就是我们在构建 Web 应用程序时所有六种配置都可用的原因。可以通过插件添加更多配置，或者我们可以在构建脚本中自己声明它们。

有趣的是，配置不仅包括依赖关系，还包括此配置产生的工件。

repositories 部分配置 Gradle 将在其中查找依赖项的存储库。 Gradle 将依赖项下载到自己的缓存中，这样就不需要在每次运行 Gradle 时都进行下载。我们可以配置多个存储库，如下所示：

repositories {
  mavenCentral()  // shortcut to maven central
  mavenLocal()    // shortcut to maven local (typically ~/.m2)
  jcenter()       // shortcut to jcenter
  maven {
    url "http://repo.company.com/maven"
  }
  ivy {
    url "http://repo.company.com/ivy"
  }
  flatDir {       // jars kept on local file system
    dirs 'libDir'
  }
}

支持 Maven、Ivy 和平面目录（文件系统）等存储库用于依赖解析和上传工件。有一些更具体的便利方法可用于常用的 Maven 存储库，例如 mavenCentral()、jcenter() 和 mavenLocal()。但是，可以使用以下语法轻松配置更多 Maven 存储库：

maven {
  url"http://intranet.example.com/repo"
}

在中央存储库之前，项目用于管理文件系统上的库，这些库大多与源代码一起签入。有些项目仍然这样做；尽管我们不鼓励这样做，但人们有理由这样做，Gradle 没有理由不支持。

重要的是要记住，Gradle 不会自动假定要搜索和 从中下载依赖项的任何存储库。我们必须在 repositories 块中明确配置至少一个存储库，Gradle 将在其中搜索工件。

WordUtils.capitalize(String str)