Getting OculiX IDE running from Eclipse #398
Replies: 8 comments 3 replies
-
|
@sengsational — the gecko likes a good use case. He likes atypical ones even more. He shuffles his carcass over an AS/400 in the morning, drops into a TK5 MVS turnkey at lunch, ends his day on a SUSE box — so an Ubuntu / Eclipse / SikuliX combo is barely a stretch. You're in good company. First thing: you're on 3.0.3 but current stable is 3.0.4. Grab it from the latest release page before anything else. On the Pick one: 1. You want to keep coding in Python (which your error tells me —
2. You want to code in Java (the direction you described in #397) → add the API jar to your Eclipse classpath. Download import org.sikuli.script.Screen;
import org.sikuli.script.Region;
Screen s = new Screen();
s.click("button.png");That's all you need — the API jar carries Pick one — don't mix them in the same Eclipse project. The That said, if you really do want to keep the Eclipse + IDE setup running for a specific reason (debugging the IDE itself, side-by-side comparison with the jar, anything else), share the details of how you imported the project — Maven multi-module via m2e, or a plain Java Project? Which folders are listed in your Java Build Path > Source? With those answers we pinpoint the missing classpath piece and the gecko nods, happy. The door's open. 🦎 |
Beta Was this translation helpful? Give feedback.
-
|
Running the IDE from Eclipse would allow me to see what underlying code runs when python code is activated (debugging Java). In my Eclipse environment, I have used the import on Oculix master GitHub starting with OculiX and have that project along with API, build-extensions, IDE, MCP, and Reporter. These are all compiling. I start org.sikuki.ide.SikuliX.java by just selecting run as Java application, and it comes up as expected. I select File > New Script and put some trivial bit, like I figured developers of the IDE have this figured out. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe this will help those schooled in the project detect where it's going wrong. |
Beta Was this translation helpful? Give feedback.
-
|
If I delete the |
Beta Was this translation helpful? Give feedback.
-
|
@sengsational So try again with the branch |
Beta Was this translation helpful? Give feedback.
-
|
@sengsational |
Beta Was this translation helpful? Give feedback.
-
|
@sengsational |
Beta Was this translation helpful? Give feedback.
-
|
@sengsational — first, @RaiMan's three quick pointers above (try Now the question I'd like to ask back, because your answer changes my next reply : What's the specific reason you want the IDE running from Eclipse rather than the standalone jar? There are three legitimate answers I can think of, and each one points to a different path : 1. You want to debug the IDE itself — step through the Sikuli boot sequence, the Jython initialisation, the GUI lifecycle. Totally valid, and rare among current users — the gecko respects archaeology. If that's it, I'll walk you through importing the project as a Maven multi-module via m2e so 2. You want side-by-side comparison — IDE running in Eclipse next to the standalone jar, to compare behaviour or test changes before building a new artefact. Also valid, especially for an aspiring framework author. Same m2e setup as above. 3. It was where the journey started and inertia carried you forward — also valid, no judgement. In that case @RaiMan's nudge toward For the framework work specifically (the topic of #397), you don't need the IDE source on your classpath at all. Just Tell me which of the three above matches your intent — or describe a fourth I haven't thought of — and I'll point you straight at the right setup. The gecko likes clarity before action. 🦎 |
Beta Was this translation helpful? Give feedback.
-
|
Julien, Thanks for your continuing attention. In short: mostly "3" and a little "1". I started off by importing "everything" as Maven projects, into Eclipse, so I could just run the IDE from source. One benefit from running it that way is if there's something that the IDE seems to do easily, but that same thing is giving me trouble when running Java and the framework, I can get underneath what the IDE is doing and replicate that. In other words, I might learn from runtime details of the IDE running where I can see what it's doing under the covers. Being able to examine the details of how the IDE operates is certainly a luxury, but it's one of those things that, originally, I thought would be a "all you need to do is..." (simple fix). One thing I notice is that the files left open in my old reliable 2.0.5 jar come up in the new IDE, so they're sharing configuration. That was a little spooky, and could be part of the problem. But I have removed the .Sikuli folder many times to clear out anything, but to no avail. My next step is to run the 3.0.4 jar file and suspend the attempt to run from source. It's a nice-to-have, and not on the critical path. ETA: The jar file runs perfectly, as expected. |
Beta Was this translation helpful? Give feedback.
-
|
IMHO and based on my experience with IntelliJ IDEA (left eclipse 10+ years ago), it is no problem to dive into the IDE in Debug mode, even if it is only on classpath at runtime. This is what I always do, if I have irritations with used Java stuff, that is not my own. Another modern way might be to ask some AI companion, when having problems with stuff you do not really know from inside (I myself am still at the beginning of this road, but @julienmerconsulting is expert) |
Beta Was this translation helpful? Give feedback.
-
|
@sengsational — first, let me thank you properly. Your "spooky" observation about the shared First reflex — I asked Claude. Here's its verdict :
Accurate, concise, ships in five seconds. But honestly, that's not where the value is — and that's not how I work with the tool. So here's my take — same root cause, with the why and the what's hiding right next to it the AI didn't bother surfacing. 😉 @RaiMan The actual bug
if (!Commons.isRunningFromJar()) {
jythonSupport.putSysPath(
new File(Commons.getMainClassLocation(), "LIB").getAbsolutePath(), 0);
}The path appended to On Windows and macOS, default filesystems are case-insensitive — On Linux, the filesystem is case-sensitive. The fat jar dodges this entirely because the guard at the top of the block ( Your runtime hit a path the rest of us never run on. That's a contribution. The secondary findYour first error trace also showed What happens next
Both will be tagged with a credit to your investigation. Genuinely — without your stubbornness on the Eclipse path, this bug would have stayed asleep for who knows how long. The gecko salutes. 🦎 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm on Ubuntu and can run
java -jar /home/owner/OculiX/oculixide-3.0.3-linux.jarsuccessfully.The IDE also shows properly when when I run the Sikulix.java from the IDE project, but when I try to run anything, even the same line or two that works in the jar version, it says:
Any tricks to getting it to run from Eclipse?
Beta Was this translation helpful? Give feedback.
All reactions