How to setup Robot Framework standalone jar with SwingLibrary?

Question

I'm using Robot Framework with SwingLibrary to test a Java Swing based application. Since I'm not used to Python and also don't want to setup the Python environment, I decided to go with the Robot standalone JAR version (current version 2.8.4).

My problem is the setup in combination with SwingLibrary (version 1.8.0). I don't know where to put the library such that it gets recognized by Robot.

So far, I have the following test case (mytest.txt):

*** Settings ***
Library     SwingLibrary

*** Test Cases ***
MyTestCase
     Start Application     MyApp

I tried with putting the standalone jar in conjunction with the test case in a folder, and created one subfolder (called it Lib) where I put the SwingLibrary JAR (and later also extracted the JAR). I added the SwingLibrary as well as my own application to the classpath, tried executing robot the following way:

java -Xbootclasspath/a:Lib/swinglibrary-1.8.0.jar:Lib/MyApp.jar -jar  robotframework-2.8.4.jar  mytest.txt

and also with

java -jar robotframework-2.8.4.jar mytest.txt

I always get one of the following errors:

[ WARN ] Imported library 'SwingLibrary' contains no keywords
==============================================================================
Mytest
==============================================================================
MyTestCase                                                           | FAIL |
No keyword with name 'Start Application' found.

or

[ ERROR ] Error in file 'mytest.txt': Importing test library 'SwingLibrary' failed: ImportError: No module named SwingLibrary

Answer 1

You can use the standalone jar without the -jar option, allowing you to specify the classpath in the standard manner. The main class for the standalone jar is org.robotframework.RobotFramework, so the syntax would be

java -cp robotframework-2.8.4.jar:Lib/swinglibrary-1.8.0.jar:Lib/MyApp.jar org.robotframework.RobotFramework

Slightly more verbose but it's standard and so avoids any oddnesses caused by using the non-standard -Xbootclasspath option.