> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Jeff Garratt
> Sent: 25 October 2007 21:07
> To: [email protected]
> Subject: [Smartfrog-users] Issue with Sequence component
>
> I would like the commands in Test to execute sequentially,
> terminating upon completion. I tried the following, no such luck.
> Any suggestions to what I should be doing?
>
> Thanks,
>
> ---------------------
> Test extends Sequence {
>
> projectDir TBD;
>
> installDrivers extends InstallOG {
> destDir "c:/temp";
> }
>
> perf-test extends WinNTShellScript {
> workDir PARENT:projectDir;
> processName "ant";
> cmd ["ant -f sceptre-build.xml
> test-amit-perf"];
> shouldTerminate true;
> }
>
> }
>
>
> sfConfig extends Compound {
> sfSyncTerminate true;
>
> test extends Test {
> projectDir "C:/temp";
> }
>
> }
Sequence is very good at executing components that are marked up as to
run as workflow components, meaning you set the attribute sfTerminate to
true; and they terminate themselves after deployment.
The shell script components are such components, though for historical
reasons they use shouldTerminate, as you have noticed. What I don't know
is what your InstallOG component does. Assuming it is just a copyfile,
that one is not (currently) a workflow component. Instead it is designed
to copy the file on startup and stay deployed; the derivative
DeployByCopy component deletes the file when terminated, so there is
clearly some value in having this design -sometimes.
1. I could do something about making copy more part of a workflow; file
the issue on jira.smartfrog.org and I will add to the list of things I
have to do.
2. If you are just trying to set things up for your ant run, we have a
TestCompound component under
/org/smartfrog/services/assertions/components.sf
This is how we are do almost all of Ant's own functional tests.
At its simplest, you can deploy a child named "action", then, once
deployed, the
#include "/org/smartfrog/services/assertions/components.sf"
Test extends TestCompound {
projectDir TBD;
action extends InstallOG {
destDir "c:/temp";
}
tests extends WinNTShellScript {
workDir PARENT:projectDir;
processName "ant";
cmd ["ant -f sceptre-build.xml test-amit-perf"];
shouldTerminate true;
}
}
There's lots of extra features in the TestCompound, not least of which
are the testTimeout attribute, to specify a limit on how long the tests
should take to run, and a condition which can be used so you can skip
tests on unsupported platforms.
The other nice feature is that the class can report the end of the test
run to local or remote listeners, so we can run this from a remote junit
process. In our testharness jar, there's a DeployingTestBase junit base
class, which can deploy a test compound and wait for status updates,
which are then turned into junit results
public void testCaseTCNNonexistentHost() throws Throwable {
expectSuccessfulTestRunOrSkip("org/smartfrog/test/system/components/ssh/scp/",
"tcn_nonexistent_host.sf");
}
public void testtcn_mismatched_file_listTest() throws Throwable {
expectSuccessfulTestRun("org/smartfrog/test/system/components/ssh/scp/",
"tcn_mismatched_file_list.sf");
}
I would strongly encourage you to look at the TestCompound for setting
up workflows related to testing, it being how we test most of our own
code. That doesn't mean that copy can't be made more workflow friendly,
though.
3. to run ant in its own process, I'd probably bypass the shell scripts
and put together something from RunJava that did it, with more control
over the JVM and the ant process.
4. One thing that is already on the todo list of julio or myself is
something to run ant directly with a component that starts up ant and
runs in in the current (or spawned) process:
http://jira.smartfrog.org/jira/browse/SFOS-499
the result would look something like
ReleaseBuild extends BuildFile {
dir "/home/bob/release";
}
build extends AntBuild {
dir "/home/bob/release";
targets ["clean","release"];
properties [];
}
One advantage there is that we would be able to pull ant output into the
SmartFrog log, retaining Ant's own log levels. The appropriate listener
is already in the code, so it is only writing a replacement for Ant's
own main class that needs to go in.
This is in the list as minor "it would be nice", but if you have a more
pressing need, it should not take that long to write, with a test or two.
-steve
-----------------------
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Smartfrog-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/smartfrog-users
