Comment 4 for bug 1189836
Revision history for this message
| Zed (zh2eou) wrote Re: [Bug 1189836] [request] want Sikuli API fully Maven support | #4 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
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() {
+ System.
"/SikuliX");
}
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.
that one:
public static void sikuliSetup() {
+ System.
"/SikuliX");
"/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:
> MadeForSikuliX3
> 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/
> 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:/
> >
> > 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/
> 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 go to:
> > https:/
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> [1.0.1 ok] [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/
> 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 go to:
> https:/
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> [1.0.1 ok] [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/
> 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 go to:
> https:/
>