I am working with Apama 10.3, in Software AG Designer. I have a project that I'd like to add the Pysys nature to my project, but the usual attempts (right-click on project name, project > properties, etc.) don't help. I couldn't find anything in the documentation either.
How can I work with Pysys in Designer, please? I'd like to be able to build my tests via the IDE, for consistency and convenience.
Currently eclipse/Designer doesn't have a PySys nature, but what you can do is add a generic eclipse "Python" nature – which you can do using "PyDev".
And then to launch pysys from eclipse you’ll need to add a launch configuration. There are various options but the most convenient for this purpose is the “external tool” eclipse feature.
You need to invoke pysys.py with the right environment for locating python and also Apama if you want to use it with the Apama extensions. If you’re using PySys with Apama 10.3.1+ this is easy as you can use the new capability of the apama_env.bat script to execute a command e.g. ${apama_home}\bin\apama_env pysys run –n 0 –purge. If you’re on an earlier version I’m afraid you probably need to create a trivial .bat script of your own that first runs apama_env and then pysys %*
You'll want to set the working directory in the eclipse launch config go ${project_loc}/tests so it runs all tests. Or alternatively, ${selected_resource_loc}, to invoke a specific test subtree. You could create separate launch configs for both use cases.
Related
I have written some libraries which is in groovy.
My SOAP UI scripts which is currently used for API automation is using these libraries. As there is no debug option in SOAP UI Pro It is very hard to find the failures. Can someone help to debug the groovy script from eclipse. Which is called internally by a SOAP UI Script
Here is the way I get it done:
Instead of writing the logic in a groovy script using soapUI script editor, create groovy/java (user choice) class and its methods for the same logic. Here I assume that the script would have relative lots of lines code than fewer lines.
This has couple of advantages:
Intelli sense (which is not available if you write the same in soapUI tool)
Formatting of code
Easy debug
Maintenance of the code would be simple
Have a groovy/java project in the IDE of your choice (Intellij suits better for groovy projects, personal view only). Have the logic in the form of classes / methods. Compile those classes and create a jar file. Place it under SOAPUI_HOME/bin/ext directory.
Edit the soapui invoking script(SOAPUI_HOME/bin/soapui.sh on unix or .bat on windows) and add the debug parameters in JAVA_OPTS say
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=6006.
In the groovy script, just instantiate the above created class and call the appropriate method. Use arguments to your methods, that are available in groovy script context, log, testRunner etc variables. Even the script is done with fewer lines.
Debugging In Action:
In your IDE, configure remote debugging and add your debug points where it is needed. And start debug.
Now, just run the groovy script. Go to IDE, it should stop at the point where you added the debug point. You should be to do run through it normally like how you do with java projects in your IDE.
This works best for me.
EDIT:
Of course, this requires programming knowledge, know working in IDE (assuming that user knows as per the question) configuring build/class path etc.
Can't be done. SmartBear has been talking about this since at least 2007 (when SoapUI was still owned by Eviware), but still has not delivered. Here is one source: http://community.smartbear.com/t5/SoapUI-NG/Debugging-Groovy-scripts/td-p/33995
I have recently started developing an Eclipse plugin (which is basic stuff for now) and I am struggling with "default" way to run Eclipse plugin ("Run as Eclipse application").
The Eclipse is starting another instance with my plugin already installed in it (this is default behaviour).
The problem is that when I want to re-run my plugin project and I press "run" button again (or Ctrl + F11) (and the another Eclipse instance still running) I get following message:
"Could not launch the application because the associated workspace is currently in use by another Eclipse application".
The error makes sense, and when I close "testing" Eclipse instance I am able to run my plugin again.
The question is - "is it normal routine for plugin development?". Maybe I am missing something, e.g. special arguments for Eclipse?
This seems all pretty normal. The error message is since the run configuration is specifing a workspace and when you start a second instance using the same workspace it is locked and considered in use.
What I usually do when testing a plugin is to create a run configuration (click "Run...") where I disable all the plugins I wont need when testing. This makes sure that the test starts up a couple of seconds quicker. Make sure you save that run configuration as a *.launch file aswell, that makes it quicker to test the next time. Or it can be used to share the configuration.
There's a lot you can configure in the run configuration, such as eclipse arguments, vm argument, if you want environment variables set, etc. So be sure to experiment a little.
In your run configuration. Main tab->Workspace Data ->Location text box add this:
${workspace_loc}/../runtime-EclipseApplication${current_date:yyyyMMdd_HHmmss}
Note the suffix ${current_date:yyyyMMdd_HHmmss} by this every time you launch your application new workspace will be created. So you will not get any error message saying workspace is locked.
But be careful as the folder .metadata will be different for different instances as their work-spaces are different. Thus preferences stored/retrieved by different instances are NOT in sync.
You are probably missing one important point: Eclipse supports the Java hot code replacement. Therefore in many cases you can modify your Java code while your application Eclipse instance is running, save the code and continue without restarting.
If hot code replacement is not possible, Eclipse will tell you, so you always know whether the editing changes are applied to the running instance.
This works best with more recent versions of the JVM, so consider upgrading to the latest Java 7 version, even if you write code to be compliant with Java 1.5 or 6.
Using PyDev with Eclipse Juno, I need to set some environment variables to debug every single of the many scripts in my project. I have found how to set them for a given script but it would be totally impractical to do it for all of them. The only solution I have found consists in adding those variable to the Python interpreter configuration in the Preferences. But then it will be used by all projects, which I don't want.
I thought of creating a script setting those environment variables and then launching Python, and then add it as a new Python interpreter but PyDev does not accept two interpreters with the same actual exe (I guess it checks sys.executable).
The recommended approach is really setting it at the Python interpreter level.
You can use virtualenv ( http://pypi.python.org/pypi/virtualenv ) to create a copy of your interpreter in a different path.
Just to elaborate that #FabioZadrozny's answer meets the need of the OP...
In case it hasn't occurred to you, do this:
From the menu "Window->Preference"
Navigate to "PyDev->Interpreters->Python Interpreter"
Create a new interpreter instance with "New..." button
Name it something like "python-MyProj", but use the same executable you are already using
Now in the "Environment" tab for that interpreter, set up the needed environment variable
Now, see the PyDev project to use THAT interpreter:
Right-click the project to get "Properties..."
Navigate to "PyDev-Interpreter/Grammar"
Select the newly created interpreter instance by name
Now run any python file within the project, and it should "see" the configured environment variable.
By this mechanism, you do have a "project specific setting"... which, again, for the reasons #FabioZadrozny pointed out, need to be set at the interpreter level.
I've just picked up CoffeeScript and I'm struggling to understand the deployment workflow. It seems you constantly have to compile the .coffee files before using them. (Yes, I'm aware that you can have it embedded in the browser, but that's not recommended for production applications).
Does one have to constantly (manually) compile the files before deploying? (For example, if using Eclipse, a simple Ctrl+S saves and deploys the .war/.ear on the local machine's server.) Do we have to change the build scripts (for a central, possible CI server) for deploying .coffee files? Is there anyway to have integrated compiling via the IDEs (Eclipse/Netbeans)
Any ideas/pointers/examples on this? How/what have you used in the past?
I call browserify in my Cakefile to pre-compile and package my CoffeeScript for the browser. For an example of how I call browserify as well as coffeedoc and coffeedoctest take a look at the Cakefile for my Lumenize project.
If you are using express or some other node based server, you can have your CoffeeScript compiled at request time, using tools like NibJS or as described in The Little Book on CoffeeScript (Applications chapter), you can use Stitch. BTW, I highly recommend, The Little Book. The "Compiling" chapter has information about Cake and compiling that might help you.
Yes, you should have a build script. Most CoffeeScript projects use a Cakefile for this; see, for example, 37signals' pow. With a Cakefile, you can just run
cake build
from the command line to run the build task in the Cakefile.
You can run the Cakefile on a CI server, assuming that you have Node and CoffeeScript installed on that server.
Don't deploy the coffee files, use something like "coffee -cwj" to constantly watch and compile the .coffee files into javascript (.js) files and deploy those.
The options are c=compile, w=watch and j=join the files.
See the coffee-script web site for details of the options you can pass in.
I've just started using Eclipse for Python development since we can make use of a lovely plugin I've found to enable distributed pair-programming. Anyway, the next step to getting Eclipse to integrate properly with our existing environment, would be finding a way to drive our current build tool (Waf) from within the IDE.
So the question is, is there a way I can set up Eclipse to drive Waf in a Make-like fashion? I see for Make it has some quite advanced functionality, such as being able to work out what targets are available etc. Bonus points for telling me if there is a way I could go as far as this! (I suspect the answer is that this is all built in to the Make plugin for Ecplipse).
In eclipse CDT I run waf by simply changing the build program in
ProjectPreferences->C/C++ Build->BuilderSettings
Choose External builder and then put in the path to waf
for example I use
/Users/mark/bin/waf -v -k -j2
Note that waf and make do not agree on the -j setting and you have to give i explicitly and not use the eclipse dialog.
You can use the Make targets view add the targets to call waf e.g. configure, build etc.
One issue I had is that Eclipse is hard coded to see the output from Make say Make when i changes directory so I had to patch waf
see waf issue
You could try and define a Custom builder, calling Waf with the appropriate options for the python compilation step.
(From eclipsejdt alcatel-lucent manual)
That picture (not related to Waf at all) illustrates the fact a builder can be defined as an external tool (meaning any .bat or shell you may want to call)
In that "eclipsejdt" example, the custom builder was configured like so:
To set up the builder, bring up the property dialog for project "jex1p" by selecting the project in the Package Explorer and selecting Project > Properties > Builders. Then click New..., select Program, and click OK.
Configure the builder Main tab using values:
Name : nmbldr_pre
Location : ${system_path:ksh}
Working Directory: ${build_project}
Arguments : nmbldr -p 2 -t ${build_type} -s jpre
As VonC says, the elegant way is to use a Custom builder.
Alternatively it is less work (in the short term) to hack together an ant script to do the heavy lifting and define an external builder to configure it onto the project. You may find the drawbacks of an external builder (e.g. no incremental support) mean it is worth investing the effort to do it "properly".