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
>> >>
>> >
>>
>>



Reply via email to