ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "EJ Ciramella" <>
Subject RE: Cargo
Date Fri, 27 Oct 2006 15:59:15 GMT
Honestly, it's developers thinking exec is good enough, but when the
server hangs, all of cruisecontrol hangs.  Nothing gets reported and
things just sit there.

Thanks for the tips, I'm going to keep digging. 

-----Original Message-----
From: Steve Loughran [] 
Sent: Friday, October 27, 2006 11:46 AM
To: Ant Users List
Subject: Re: Cargo

EJ Ciramella wrote:
> I'm going to try here first before moving over to the cargo mailing
> lists.  Is anyone using this via ant?

-dont be afraid to talk to them, esp on the #iRC channel. If found them 

> To start up the server for integration testing, we use the <exec> task
> to start/stop the server currently.  The bad thing is, if there is a
> test failure, the server continues to run and winds up in some funky
> state.

Problem there is more exec, isnt it.

> I'd like to use cargo to strictly start/stop the server depending on
> success/failure of the tests.
> Is there any way to fork the startup of the server via cargo?  I don't
> see anything listed on their site.

You can provide deploy/undeploy actions in the cargo task, so if you can

kill the process, then yes, you can fork it during startup.

Now, I am busy using SmartFrog to deploy applications and start tests 
all as a choreographed deployment. If you want to use it then I would 
recommend you look at the video/slides on testing under I should warn you, the stuff there is still 
stabilizing as I add new features to it (like single test execution, 
testNG support, etc).

Before I moved to in-smartfrog testing, I had an ant task to do more 
generic functional testing than cargo,<functionaltest>. It will start an

application in one thread, in another wait for a probe to succeed, run a

sequence of actions and then finally some teardown actions. It will even

kill the app if the teardown doesnt do it:

     <sf-functionaltest testTimeout="600" shutdownTime="10">
         <sf-startdaemon-debug failonerror="false" spawn="false"/>
         <socket port="${smartfrog.daemon.port}" server="localhost"/>
           <sysproperty key="test.classes.dir"
           <!--all properties beginning with test-->
             <propertyref prefix="test."/>
             <path refid=""/>
           <batchtest todir="${}">
             <!-- bulk test case -->
             <fileset dir="${test.classes.dir}">
               <include name="org/smartfrog/**/system/**/*Test.class"/>
         <fail if="failure">Junit failed</fail>
         <sf-stopdaemon failonerror="false"/>
         <sf-junitreport data="${}"

It is hidden in the smartfrog SVN repository and in the source 
distributions; feel free to use it. the source is LGPL:

look at the execute() method if you want to see complexity. You'd be 
hard press to encode that logic in a build file.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message