sikuli-driver team mailing list archive

[RaiMan <rmhdevelop@xxxxxx>]

** Changed in: sikuli
       Status: New => Fix Committed

** Changed in: sikuli
    Milestone: None => x1.0-rc2

-- 
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:
  [feature 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 ;-)