Jason, One of the things we discussed was to write/modify our plugins such that some oft used goals like start/stop servers, deploy/undeploy apps, start/stop apps will write it's output to a surefire like xml in the target/surefire-reports dir.
Using the cargo plugin would not give us this ability to log the failures of the above popular goals in the surefire dir and to a site report eventually. Hmmm.. ?? Cheers Prasad On 8/8/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
More reasons for us to switch ;-) --jason On Aug 8, 2006, at 6:56 PM, Prasad Kashyap wrote: > Yep.. The last time I checked, I believe Cargo support for the G's > version of Jetty container needed Java 5 support. But we should > revisit that again. > > Cheers > Prasad > > On 8/8/06, Bill Dudney <[EMAIL PROTECTED]> wrote: >> Cool thing is someone else has already done it Cargo currently >> supports G 1.1. >> >> :-) >> >> -bd- >> >> On Aug 8, 2006, at 5:33 PM, Jason Dillon wrote: >> >> > I think that in general it would be good to have cargo support :-) >> > >> > --jason >> > >> > >> > On Aug 8, 2006, at 4:23 PM, Bill Dudney wrote: >> > >> >> Hi Prasad, >> >> >> >> The cargo plugins [1] might be another place to check to start and >> >> stop the server. >> >> >> >> I've used them before for tomcat and its good stuff for running >> >> integration tests. >> >> >> >> And what can I do to help? >> >> >> >> TTFN, >> >> >> >> -bd- >> >> >> >> [1] http://cargo.codehaus.org >> >> >> >> On Aug 4, 2006, at 10:00 AM, Prasad Kashyap wrote: >> >> >> >>> With the m2migration ready to be merged into trunk, I have >> resumed >> >>> work on the itests for Geronimo again. >> >>> >> >>> Approx 30% of our code is covered by component level tests >> that are >> >>> embedded in each module. These tests are written as junit test >> cases >> >>> and run by Maven surefire plugin. >> >>> >> >>> The itests will cover system level tests by testing the >> >>> functionalities that an end-user would use on a fully assembled >> >>> Geronimo distribution. Therefore to the extent possible, our >> itests >> >>> and it's testcases should use the very same external APIs and >> >>> workflows that a user would use. >> >>> >> >>> We have been using the startRemoteServer and stopRemoteServer >> >>> goals in >> >>> the geronimo-deployment-plugin (g-d-p) to start and stop a >> >>> server. We >> >>> have always used these "remote" goals and have never used the >> in-vm >> >>> goals startServer and stopServer. >> >>> >> >>> I propose that we convert the in-vm goals startServer and >> stopServer >> >>> to be ant mojos from their existing java mojos. Invoking the ant >> >>> mojo >> >>> goals in our itests will ensure that our tests are using the same >> >>> APIs >> >>> that a end-user uses. Thus we shall no longer use internal >> hooks in >> >>> the code to start and stop the server. >> >>> >> >>> Thoughts ? Comments ? Advice ? >> >>> >> >>> Cheers >> >>> Prasad >> >> >> > >> >>
