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.krist...@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 >> <ostew...@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-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
