如何使用由 Maven 坐标定义的战争来运行 jetty:run-war？

Posted 2023-02-27

【中文标题】如何使用由 Maven 坐标定义的战争来运行 jetty:run-war？

【英文标题】：How to run jetty:run-war using a war defined by maven coordinates?

【发布时间】：2011-01-16 12:46:12

【问题描述】：

背景：我正在一个 Maven 项目中设置功能测试模块。我们使用maven-jetty-plugin 进行测试。

我已经设置了 jetty 插件as described here（可以很好地使用 Failsafe 插件），但我想做的是使用 jetty 从我们的主 Web 模块部署战争工件（刚刚在功能测试模块运行时安装到本地 maven 存储库中）。

jetty 插件的run-war goal 有一个<webApp> 元素，它采用字符串路径来部署战争。我更愿意使用我们的 web 模块定义的 maven 坐标来指定要部署的战争。有没有办法做到这一点？

可能的解决方法：

Section 4.13 of "Better Builds with Maven" 描述了使用 cargo 来部署使用 maven 坐标指定的战争，但考虑到我们正在使用码头，这是严重的矫枉过正。 更合理的 IMO 是使用 dependency:copy 将刚刚构建和安装的战争工件复制到功能测试模块目标目录中的固定路径，然后我可以在 jetty 插件的 <webApp> 配置元素中提供该路径。

【参考方案1】：

jetty 插件的 run-war 目标有一个元素，它采用字符串路径来部署战争。我更愿意使用我们的 web 模块定义的 maven 坐标来指定要部署的战争。有没有办法做到这一点？

这不是真正应该使用的maven jetty插件，插件部署当前模块的war，默认不支持你想做的。

“使用 Maven 更好地构建”的第 4.13 节描述了使用货物部署使用 maven 坐标指定的战争，

是的，Cargo 可以以干净的方式做到这一点。

但考虑到我们正在使用码头，这是严重的矫枉过正。

我不同意。首先，jetty 插件不支持开箱即用的功能（因此它可能不是正确的工具）。其次，严重的矫枉过正被高度夸大了，实际上是一种误解，特别是考虑到货物对嵌入式 Jetty 的配置很少（零？）。

更合理的 IMO 是使用 dependency:copy 将刚刚构建和安装的战争工件复制到功能测试模块的目标目录中的固定路径

无意冒犯，但你的整个问题听起来有点像：我有一把锤子，它可以用来做钉子，我可以用它来做螺丝，因为拿螺丝刀似乎是一种严重的矫枉过正吗？ 要回答这个问题（这就是您所说的），您可以使用dependency:copy 并使用 maven jetty 插件来完成整个工作，但这是一个 hack（因为您实际上并没有问任何问题，我猜你想对此发表意见）。当然最终的决定权在你:)

以防万一，以下是我将如何使用 Cargo 实现此功能：

<dependencies>
  <dependency>
    <groupId>war group id</groupId>
    <artifactId>war artifact id</artifactId>
    <type>war</type>
    <version>war version</version>
  </dependency>
  ...
</dependencies>
...
<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.cargo</groupId>
      <artifactId>cargo-maven2-plugin</artifactId>
      <configuration>
        <!-- Container configuration -->
        <container>
          <containerId>jetty6x</containerId>
          <type>embedded</type>
        </container>
        <!-- Configuration to use with the container or the deployer -->
        <configuration>
          <deployables>
            <deployable>
              <groupId>war group id</groupId>
              <artifactId>war artifact id</artifactId>
              <type>war</type>
              <properties>
                <context>war context</context>
              </properties>
            </deployable>
          </deployables>
        </configuration>
        <!-- Don't wait, execute the tests after the container is started -->
        <wait>false</wait>
      </configuration>
      <executions>
        <execution>
          <id>start-container</id>
          <phase>pre-integration-test</phase>
          <goals>
            <goal>start</goal>
          </goals>
        </execution>
        <execution>
          <id>stop-container</id>
          <phase>post-integration-test</phase>
          <goals>
            <goal>stop</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
    ...
  </plugins>
  ...
</build>

而且我认为这在客观上不能被定性为“严重的矫枉过正”。

【讨论】：

“严重矫枉过正”的评论来自我最初看到的 cargo 只与 Geronimo 一起使用——当时我推测它是一个部署工具，而不是一个 webapp 容器（我没有'在昨天之前没听说过，耸耸肩）。无论如何，你绝对是对的，cargo 是要走的路，你在上面分享的插件配置是我需要的 99%。感谢您的帮助和澄清。

@Chas 没问题。我很高兴我当时澄清了这一点。祝你好运。