[1.0.1 ok] [request] want Sikuli API fully Maven supported

[RaiMan]

--- fixed with 1.0.1: everything now is in the jar. files needed in the outside world are checked/exported/updated at runtime (e.g. the native libs)
so currently no need for Maven Central (but is on the list for 1.1)

Hi, I've been having some difficulty in trying to set up the API to use with a maven project - specifically in that when I try to set it up as a dependency from a local repository, I have trouble linking the non-jar files to the project (getting the Native library could not be extracted nor found: VisionProxy error).

Also, what would be a good way for me to set up multiplatform project? I assume I can't simply dump all the files from the separate APIs into a Single SikuliX folder.

Finally, are you planning to release a Maven version to the global repository? Something that could handle all the setup just using the pom and such.

[RaiMan (raimund-hocke)]

The native libs will be in the jar (fully for Windows and Mac, partly for Linux) and fully self extracting.

To have "one for all" is a bit tricky, but I will think about that option.

[Zed (zh2eou)]

Hi Raimund,
Am happy to report that I've finally got the build script for the
VisionProxy working on Linux! Using Ubuntu 12.04, and grabbing opencv-dev
and tesseract-dev with apt-get seemed to have satisfied the library
requirements (though I believe the opencv version is 2.3.x using apt-get,
so that may not be ideal). Just needed to -Include the JAVA_HOME directory
for building the javawrapper and changing the libFolders to use /usr/lib
instead of /usr/local/lib.

I do still seem to run into an issue with it when I try to add it (that
being sikuli-java.jar) as a custom Maven dependency, though. It starts to
complain that the file is not the one that was setup using
sikuli-setup.jar. I noticed you did away with some of the libPath stuff in
the Settings class, so I assume that it's all being taken of by the setup
file. But if I want to run it in this more portable way, how would I make
it work?

-Zhe

On Tue, Jul 16, 2013 at 8:15 AM, RaiMan <email address hidden> wrote:

> ** Description changed:
>
> + --- fixed with 1.0.1: everything now is in the jar. files needed in the
> outside world are checked/exported/updated at runtime (e.g. the native libs)
> + so currently no need for Maven Central (but is on the list for 1.1)
> +
> Hi, I've been having some difficulty in trying to set up the API to use
> with a maven project - specifically in that when I try to set it up as a
> dependency from a local repository, I have trouble linking the non-jar
> files to the project (getting the Native library could not be extracted
> nor found: VisionProxy error).
>
> Also, what would be a good way for me to set up multiplatform project? I
> assume I can't simply dump all the files from the separate APIs into a
> Single SikuliX folder.
>
> Finally, are you planning to release a Maven version to the global
> repository? Something that could handle all the setup just using the pom
> and such.
>
> ** Changed in: sikuli
> Importance: High => Critical
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1189836
>
> Title:
> [request] want Sikuli API fully Maven supported
>
> Status in Sikuli:
> Fix Committed
>
> Bug description:
> --- fixed with 1.0.1: everything now is in the jar. files needed in the
> outside world are checked/exported/updated at runtime (e.g. the native libs)
> so currently no need for Maven Central (but is on the list for 1.1)
>
> Hi, I've been having some difficulty in trying to set up the API to
> use with a maven project - specifically in that when I try to set it
> up as a dependency from a local repository, I have trouble linking the
> non-jar files to the project (getting the Native library could not be
> extracted nor found: VisionProxy error).
>
> Also, what would be a good way for me to set up multiplatform project?
> I assume I can't simply dump all the files from the separate APIs into
> a Single SikuliX folder.
>
> Finally, are you planning to release a Maven version to the global
> repository? Something that could handle all the setup just using the
> pom and such.
>
> To manage notifications about this bug ...

[RaiMan (raimund-hocke)]

Hi Zhe,

currently (version 1.0.1) after setup, the sikuli-java.jar contains the bundled libVisionProxy.so and in the setup folder there is a folder libs, that should contain these 3 files:
MadeForSikuliX32L.txt
libJXGrabKey.so
libVisionProxy.so

If you now build your own libVisionProxy.so, simply replace it in the above libs folder.

It is heavily recommended, to not move the Sikuli stuff around.
At runtime the presence of the libs folder and its content is checked and recreated if necessary from the jar.
Only if the modification time of the jar content is newer, it is updated if present.
So in your case, your own libVisionProxy.so is protected as long as in the same folder as the jar there is a libs folder containing the above 3 files.

So if you really need to be „more portable“, you always have to bundle the jar with the modified libs folder, to keep your own libVisionProxy.so.

The next version will allow, to add your own libVisionProxy.so already at setup to the produced jars.

Raimund.

Am 06.11.2013 um 19:35 schrieb Zhe Zhou <email address hidden>:

Hi Raimund,
Am happy to report that I've finally got the build script for the
VisionProxy working on Linux! Using Ubuntu 12.04, and grabbing opencv-dev
and tesseract-dev with apt-get seemed to have satisfied the library
requirements (though I believe the opencv version is 2.3.x using apt-get,
so that may not be ideal). Just needed to -Include the JAVA_HOME directory
for building the javawrapper and changing the libFolders to use /usr/lib
instead of /usr/local/lib.

I do still seem to run into an issue with it when I try to add it (that
being sikuli-java.jar) as a custom Maven dependency, though. It starts to
complain that the file is not the one that was setup using
sikuli-setup.jar. I noticed you did away with some of the libPath stuff in
the Settings class, so I assume that it's all being taken of by the setup
file. But if I want to run it in this more portable way, how would I make
it work?

-Zhe

On Tue, Jul 16, 2013 at 8:15 AM, RaiMan <email address hidden> wrote:

> ** Description changed:
>
> + --- fixed with 1.0.1: everything now is in the jar. files needed in the
> outside world are checked/exported/updated at runtime (e.g. the native libs)
> + so currently no need for Maven Central (but is on the list for 1.1)
> +
> Hi, I've been having some difficulty in trying to set up the API to use
> with a maven project - specifically in that when I try to set it up as a
> dependency from a local repository, I have trouble linking the non-jar
> files to the project (getting the Native library could not be extracted
> nor found: VisionProxy error).
>
> Also, what would be a good way for me to set up multiplatform project? I
> assume I can't simply dump all the files from the separate APIs into a
> Single SikuliX folder.
>
> Finally, are you planning to release a Maven version to the global
> repository? Something that could handle all the setup just using the pom
> and such.
>
> ** Changed in: sikuli
> Importance: High => Critical
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1189836
>
> Title:
> ...

[Zed (zh2eou)]

Yeah I tried replacing the libVisionProxy.so in the libs folder and it make
Sikuli-IDE work for Linux. Before, it used to crash whenever I start any of
the image recognition issues, but not it proceeds.

In context of setting the portable libs, that's what I was doing before
using version 1.0. Below is the bit of code I use for setup and to set the
libPaths before running my stuff:

public static void sikuliSetup() {

        Settings.OcrTextRead = true;

        Settings.OcrTextSearch = true;

        System.out.println(System.getProperty("os.name") + " - Using Java "
+ System.getProperty("os.arch"));

        System.setProperty("sikuli.Home", System.getProperty("user.dir") +
"/SikuliX");

        Settings.libPath = System.getProperty("sikuli.Home") + "/libs";

        Settings.libPathMac = Settings.libPath;

    }

Then I had a custom build script that copied over the correct library files
to the SikuliX/libs folder depending on what platform you choose to build
it for.

When I swap out the version 1.0 sikuli-script.jar for the version 1.0.1
sikuli-java.jar - installing it as a custom maven dependency - for the new
one, some of the Settings seem to go away (also seem to have been moved to
the org.sikuli.basics package), in particular the libPath one. I noticed
there is a Settings.libSourcebase variable, so I tried to replace it using
that one:

public static void sikuliSetup() {

        Settings.OcrTextRead = true;

        Settings.OcrTextSearch = true;

        System.out.println(System.getProperty("os.name") + " - Using Java "
+ System.getProperty("os.arch"));

        System.setProperty("sikuli.Home", System.getProperty("user.dir") +
"/SikuliX");

        Settings.libSourcebase = System.getProperty("sikuli.Home") +
"/libs";

}

Then I updated the libs folder with the 1.0.1 ones (just testing my Mac for
the moment, haven't tried Linux or Windows yet), and tried to run it.
However, I get the following error (see attached screenshot).
On Nov 6, 2013 12:26 PM, "RaiMan" <email address hidden> wrote:

> Hi Zhe,
>
> currently (version 1.0.1) after setup, the sikuli-java.jar contains the
> bundled libVisionProxy.so and in the setup folder there is a folder libs,
> that should contain these 3 files:
> MadeForSikuliX32L.txt
> libJXGrabKey.so
> libVisionProxy.so
>
> If you now build your own libVisionProxy.so, simply replace it in the
> above libs folder.
>
> It is heavily recommended, to not move the Sikuli stuff around.
> At runtime the presence of the libs folder and its content is checked and
> recreated if necessary from the jar.
> Only if the modification time of the jar content is newer, it is updated
> if present.
> So in your case, your own libVisionProxy.so is protected as long as in the
> same folder as the jar there is a libs folder containing the above 3 files.
>
> So if you really need to be „more portable“, you always have to bundle
> the jar with the modified libs folder, to keep your own
> libVisionProxy.so.
>
> The next version will allow, to add your own libVisionProxy.so already
> at setup to the produced jars.
>
> Raimund.
>
> Am 06.11.2013 um 19:35 schrieb Zhe Zhou <email address hidden>:
>
> Hi Raimund,
> Am happy to report that ...