Re: [itests] Modify the geronimo-deployment-plugin ?
Kay :-) --jason On Aug 9, 2006, at 6:52 PM, Prasad Kashyap wrote: 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 >> >> >> > >> >>
Re: [itests] Modify the geronimo-deployment-plugin ?
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 >> >> >> > >> >>
Re: [itests] Modify the geronimo-deployment-plugin ?
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 >> >
Re: [itests] Modify the geronimo-deployment-plugin ?
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 >> >
Re: [itests] Modify the geronimo-deployment-plugin ?
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
Re: [itests] Modify the geronimo-deployment-plugin ?
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
Re: [itests] Modify the geronimo-deployment-plugin ?
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
Re: [itests] Modify the geronimo-deployment-plugin ?
On Aug 4, 2006, at 9:00 AM, Prasad Kashyap wrote: 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. I think this is a good idea, helps get additional testing of those commands that folks will be using. I would suggest that we hide the details of invoking these into a set of mojo's... I know we can use antrun but that exposes all of the bits needed in each pom which is unneeded bloat and will be more difficult to manage. Along those lines, we don't really need any Ant-bits to do this. plexus-util has enough support for use to invoke external commands and handle stream interactions so we can then parse the output for validation. I don't think we need to use Ant here. But, I also think that Ant provides an awesome set of components for builds, so if we do need them, then it is easy enough to programatically invoke the tasks from inside of a mojo... I've done this many times before. --jason
Re: [itests] Modify the geronimo-deployment-plugin ?
Hi David, Please see comments inline - On 8/4/06, David Jencks <[EMAIL PROTECTED]> wrote: On Aug 4, 2006, at 9: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 ? I probably don't understand what you are proposing well enough, but I don't see how running geronimo in the same vm as the tests will more closely approximate the users experience: most people will not be running geronimo in the same vm as their client. Is there some other advantage of using only one vm? Actually I am not saying that we should use only 1 vm. What I am proposing is that we use ANT to invoke the same CLIs that a user would invoke. In fact, I'd much rather prefer the start and stop server be forked off. I mentioned replacing the existing in-vm goals just because they were not being used. We may very well leave them there and add new ANT mojos to the mix. BTW I am really looking forward to reasonable itests :-) I wrote a couple of tiny sample apps to check if I'd fixed some bugs recently and hope these can turn into itests. Oh cool. Let's talk about this. thanks david jencks > > Cheers > Prasad
Re: [itests] Modify the geronimo-deployment-plugin ?
On Aug 4, 2006, at 9: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 ? I probably don't understand what you are proposing well enough, but I don't see how running geronimo in the same vm as the tests will more closely approximate the users experience: most people will not be running geronimo in the same vm as their client. Is there some other advantage of using only one vm? BTW I am really looking forward to reasonable itests :-) I wrote a couple of tiny sample apps to check if I'd fixed some bugs recently and hope these can turn into itests. thanks david jencks Cheers Prasad
