still a bit invasiv but you could split stubserver-maven-plugin into
two plugins, one for starting and for stopping. that gives you at
least a "readable" pom.

- Kristian

On Sat, Nov 19, 2011 at 1:33 AM, Oliver Stewart
<[email protected]> wrote:
> Hello.  We are trying to perform automated integration testing in our Maven
> build.  We have our webapp starting via the Cargo plugin in the
> pre-integration-test phase, then stopping in the post-integration-test
> phase.  This seems like a straightforward application of the Maven
> lifecycle.  Because our application needs to interact with an external
> server and we need to stub this server for the purpose of testing, we need
> to be able to start this stub server before Cargo starts and stop the stub
> server after Cargo stops.  This seems like an extension of the same problem
> we're solving with the pre- and post-integration-test phases, but Maven
> doesn't seem to support more than one of these pre and post actions in a
> logical way (i.e. nesting within one another).  Essentially, we'd need
> either a nested order of start/stop executions in the pre- and
> post-integration-test phases or pre-pre-integration-test and
> post-post-integration-test phases into which to add our goals.
>
> Here's what we'd like to happen:
> phase pre-integration-test:
> stub-server:start
> cargo:start
>
> phase post-integration-test:
> cargo:stop
> stub-server:stop
>
> Initially we thought we might be able to do this by writing our own plugin,
> but it appears the goals we specify in an execution will be run in the
> order they are configured in the pom.  So we get the reverse order we'd
> like in the post-integration-test phase:
>
> phase pre-integration-test:
> stub-server:start
> cargo:start
>
> phase post-integration-test:
> stub-server:stop
> cargo:stop
>
> This is with plugin definitions like:
>      <plugin>
>        <groupId>com.example</groupId>
>        <artifactId>stubserver-maven-plugin</artifactId>
>        <version>1.0-SNAPSHOT</version>
>        <executions>
>          <execution>
>            <id>start-server</id>
>            <phase>pre-integration-test</phase>
>            <goals>
>              <goal>start</goal>
>            </goals>
>          </execution>
>          <execution>
>            <id>stop-server</id>
>            <phase>post-integration-test</phase>
>            <goals>
>              <goal>stop</goal>
>            </goals>
>          </execution>
>        </executions>
>      </plugin>
>      <plugin>
>        <groupId>org.codehaus.cargo</groupId>
>        <artifactId>cargo-maven2-plugin</artifactId>
>        <version>1.0.6</version>
>        <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>
>
>
> We've been looking at other ways of doing this, such as using the @execute
> annotation, but we haven't found a straightforward way to do it without
> hijacking a different phase such as verify or splitting up the
> configuration in a way that would be terribly confusing to anyone trying to
> understand our build.  The only other thing we haven't tried that we can
> think of is to redefine DefaultLifecycleMapping entirely to add new phases
> for our integration-test module.  That seems somewhat invasive, but if it's
> a good way to do it, we're willing to go that route.
>
> Does Maven provide a facility for this, or is there a reasonable way to do
> it?
>
> Thanks,
> Oliver
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to