You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Oliver Stewart <os...@cyrusinnovation.com> on 2011/11/18 21:03:49 UTC

Multiple goals per phase

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

Re: Multiple goals per phase

Posted by Manfred Moser <ma...@mosabuam.com>.
You could have all the stub server code in a normal library jar and have
the two plugins be very shallow and just depend on the library..

just saying..

On Fri, November 18, 2011 1:17 pm, Oliver Stewart wrote:
> Thanks Kristian,
> We were hoping to avoid that approach, as it would prevent us from keeping
> the related stub server code together, but it's good to have a backup
> plan.
>
> Cheers,
> Oliver
>
> On Fri, Nov 18, 2011 at 3:15 PM, kristian <m....@web.de> wrote:
>
>> 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
>> <os...@cyrusinnovation.com> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Multiple goals per phase

Posted by Oliver Stewart <os...@cyrusinnovation.com>.
Thanks Kristian,
We were hoping to avoid that approach, as it would prevent us from keeping
the related stub server code together, but it's good to have a backup plan.

Cheers,
Oliver

On Fri, Nov 18, 2011 at 3:15 PM, kristian <m....@web.de> wrote:

> 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
> <os...@cyrusinnovation.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: Multiple goals per phase

Posted by kristian <m....@web.de>.
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
<os...@cyrusinnovation.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org