java - Maven tomcat 插件 : tomcat7:run or tomcat7:run-war?

Question

我在我的 Java 网络应用程序中使用 tomcat7-maven-plugin。现在我可以使用命令 mvn clean tomcat7:run 运行我的 Web 服务器。最近我注意到 https://tomcat.apache.org/maven-plugin-2.0/tomcat7-maven-plugin/plugin-info.html 中有另一个名为 tomcat7:run-war 的命令。 ，它说:

tomcat7:run:
Runs the current project as a dynamic web application using an embedded Tomcat server.

tomcat7:run-war:
Runs the current project as a packaged web application using an embedded Tomcat server.

我知道命令 tomcat7:run-war 会将我的应用程序打包到 jar 或 war 文件中，然后在嵌入式服务器。我的问题是，在什么情况下应该使用这个命令，tomcat7:run 不就可以了吗？或者也许运行打包的应用程序会有更高的性能？我不知道。提前致谢。

Answer 1

简答

运行的应用程序和服务器性能是相等的。但是，您通常希望使用 run-war，因为它为您提供了传送 war 文件的额外好处。如果您绝对需要让您的应用程序尽可能快地在本地运行(几乎从来没有这种情况)，您想要使用 run。

---

细节来了

让我们从什么是 war 文件以及创建它的目的开始:

WAR. Is the extension of a file that packages a web applicationdirectory hierarchy in ZIP format and is short for Web Archive. Javaweb applications are usually packaged as WAR files for deployment.[Baeldung]

为什么 java 网络应用程序被打包为 WAR？

因为 WAR 不仅是一个 zip 文件，而且(正确构建)强制执行 Java Web 应用程序规范。您可以在任何 容器上部署和运行 war 文件。结帐Wikipedia以获得更多优势。

不同的目标，不同的结果

目标 tomcat:run 和 tomcat:run-war 都在嵌入式 tomcat 服务器上启动您的应用程序。 tomcat:run-war 包含一个额外的 package 目标，用于将您的应用程序打包到 WAR 文件中。然后，嵌入式 tomcat 服务器将解压缩此 WAR 文件，以便能够运行该应用程序。所以应用程序和服务器是相同的，但是 run-war 的结果不同，因为您得到了额外的 WAR 文件。

但是那个 WAR 文件有什么用呢？

首先，除了构建时间多几秒之外，它没有任何缺点。甚至热插拔工具和功能也可以在两者之间使用 WAR 文件。创建 WAR 文件作为该目标的一部分的主要原因是:

• 测试
• 多次部署
• CI 管道
• 归档

测试。构建 WAR 文件意味着您的构建管道经历了 WAR 构建的所有步骤。由于您稍后将部署该 WAR 文件(提醒:它是容器的标准)，您可以测试“构建”、“解包”和“部署”步骤是否正常工作。此外，如果没有，您可以检查文件的结构。

多次部署。您可以在本地构建和运行该应用程序，但您仍然可以将该 WAR 文件部署到您正在运行的多个容器中。在某些行业场景中，您需要确保您的 WAR 文件在不同的容器上运行，并且您可以使用该文件将其部署到任何地方。

CI 管道。您可能不仅希望在本地应用程序，而且希望将结果集成到您的持续集成中。也许您甚至会自动将本地构建部署到测试服务器，但更有可能的是，您在构建 WAR 的 CI 服务器上有一个自动化过程，在某些测试或暂存系统上运行它，然后在工作正常时转发 WAR .

归档。您可能希望保留所有过去构建的 WAR 文件。可能是出于提到的其他原因之一，或者只是作为快速历史访问的备份。查看磁盘空间和内存使用情况如何随着应用程序的增长而变化也很有趣。归档 WAR 文件是调查该问题的一种方式。它们也可能被部署到 WAR 存档服务器。

---

结论

这两个目标都有其用途，但通常更倾向于使用 run-war 目标，因为您可以通过额外构建 WAR 文件获得好处。

免责声明

由于这个主题有点过时，我可能会添加以下内容:我只是进行历史回顾。对于每个单独的用例，今天的用例和需求可能会有所不同。一些流程、maven-goals 和插件已经过时或出现了更好的做法。我只是在解释制定该目标时背后的可能意图。