sikuli-driver team mailing list archive
-
sikuli-driver team
-
Mailing list archive
-
Message #00465
[Bug 696822] Re: [request] want a real standalone sikuli-script.jar
The current instructions are inadequate.
This is a significant issue that is blocking use of Sikuli,
I still can't get scripts to execute
My project will be terminated this Friday unless I can get my previously
working Sikuli scripts to work from within NetBeans.
One error leads to another, I can no longer import subprocess even in
the Sikuli IDE, this breaks most of my scripts.
--
You received this bug notification because you are a member of Sikuli
Drivers, which is subscribed to Sikuli.
https://bugs.launchpad.net/bugs/696822
Title:
[request] want a real standalone sikuli-script.jar
Status in Sikuli:
Fix Committed
Bug description:
scope: Sikuli X on all platforms.
--- Request:
Available with the downloadable package I want to have a fully self contained sikuli-script-standalone.jar. No fiddling around with dynamic link libraries and system path's. It should just be sufficient to have it in the java class path and if needed in the python path (sys.path, the need to say sikuli-script-standalone.jar/Lib is acceptable). from sikuli.Sikuli import * should then be all I have to do.
Possible Solution: pack ALL needed native libraries in the jar file and copy them as needed at runtime into the appropriate temp folder so they can find themselves automatically. It should be one .jar for all platforms to be able to pack it together with the scripts.
--- Current Situation:
When you decide (based on whatever reasons) to not use the Sikuli IDE to edit, run and debug your scripts, you only need two resources from the package you download from Sikuli home:
- the folder that contains the native libraries (openCV (has to be installed seperately on Linux) and some system specifics)
- sikuli-script.jar
With some practical differences on the platforms you have to take care:
- that Sikuli finds the native libraries (mainly using path specifications in system path)
- to have sikuli-script.jar in the java class path
- to have sikuli-script.jar/Lib in the Python path (sys.path)
- to say "from sikuli.Sikuli import * " in your main module and all imported modules using Sikuli features
- preserve the .sikuli/.skl folder structure if you want to use the new import/imagePath feature
(I know, that there are currently problems with 64-Bit environments,
but this has nothing to do with this principal approach)
This is all you need for the Python level.
If you want to use Sikuli features on the Java level, it is principally the same (but no need for Python path, Sikuli features are imported using org.sikuli.script.*)
Having this prepared you can use IDE's like NetBeans or Eclipse (you
might need plugins for Python) to edit, run and debug your scripts and
run your scripts using plain Jython or Java.
With the new features of Sikuli X it is now possible to manage your
image libraries and some related scripts with Sikuli IDE, but
completely using e.g. NetBeans to do the programming (edit, run,
debug, ...) of your workflows and/or test suites.
--- Current technical solution regarding the dynamic libraries:
When the initialization logic in sikuli-script.jar (triggered with the first import sikuli.Sikuli) realizes, that it is not running in the IDE context, it copies some proxy dynamic libraries contained in sikuli-script.jar to a temp directory, that in turn will try to find the other above mentioned native libraries. this location is maintained in the java system property java.library.tmpdir and can be set by the script before the first import of Sikuli features.
On Windows currently it is sufficient to add the following to the system path:
path-to-the-folder-containing-the-dynamicLibraries;path-to-java\jre6\bin
On Linux it should be similar
On Mac you have to manipulate the jnilib's and dylib's to contain the
correct pointers to each other, depending on the location of the
libraries (if interested contact me directly). the most flexible way
is to use the directive @loader_path.
--- Specifying sikuli-script.jar/Lib in IDE's
in some IDE/platform combinations it is not possible to specify this in the settings panels.
Then you have the following choices:
- in your main script modify sys.path before the first import of Sikuli features
- edit the relevant configuration file by hand: (Netbeans: User folder .netbeans/build.properties, Eclipse: I do not know ;-)
References