How to run jetty:run-war using a war defined by maven coordinates?

Question

Background: I'm setting up a functional tests module in a maven project. We use the maven-jetty-plugin for testing.

I've got the jetty plugin set up as described here (to play nicely with the Failsafe plugin), but what I'd like to do is deploy the war artifact from our main web module using jetty (which has just been installed into the local maven repo by the time the functional test module is running).

The jetty plugin's run-war goal has a <webApp> element which takes a string path to a war to deploy. I'd much rather specify the war to deploy using the maven coordinates defined by our web module. Is there any way to do this?

Possible workarounds:

1. Section 4.13 of "Better Builds with Maven" describes using cargo to deploy a war specified using maven coordinates, but that's serious overkill given that we're using jetty.
2. More reasonable IMO is using dependency:copy to copy the just-built-and-installed war artifact to a fixed path in the functional tests module's target directory, which I can then provide in the jetty plugin's <webApp> configuration element.

Answer 1

The jetty plugin's run-war goal has a element which takes a string path to a war to deploy. I'd much rather specify the war to deploy using the maven coordinates defined by our web module. Is there any way to do this?

This is not really the maven jetty plugin is supposed to be used, the plugin deploys the war of the current module, what you want to do is not supported by default.

Section 4.13 of "Better Builds with Maven" describes using cargo to deploy a war specified using maven coordinates,

Yes, Cargo can do this in a clean way.

but that's serious overkill given that we're using jetty.

I don't agree. First, the jetty plugin doesn't support what you want to do out of the box (so it may not be the right tool). Second, serious overkill is highly exaggerated, a misconception actually, especially given that cargo requires very little configuration (zero?) for an embedded Jetty.

More reasonable IMO is using dependency:copy to copy the just-built-and-installed war artifact to a fixed path in the functional tests module's target directory

No offense but your whole question sounds a bit like: I have a hammer, it was fine for a nail, can I use it for a screw given that getting a screw driver seems a serious overkill? To answer this question (which is somehow what you are saying), you can use dependency:copy and get the whole thing working with the maven jetty plugin, but this is a hack (and since you're actually not asking any question, I guess you wanted an opinion on this). Of course the final decision belongs to you :)

Just in case, here is how I would implement this with 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>

And I don't think that this can be objectively qualified as a "serious overkill".