Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Proposal: drop the Java remote server, run the keywords on the oculix PyPI package

Abierto
  • ¿Algo no está bien?
#205 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
java, python
Área
desktop-dev, testing-qa

Línea de trabajo

Start by reading the existing Java tree, pom and assembly configuration, then inspect the oculix PyPI package and its stdio process model. The proposed change removes the Java server and Maven build, moves all 76 keywords to Python, and declares oculix in install_requires while preserving names, arguments and behavior. Done means the package installs and exposes the same Robot library without the fat jar.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

Portuguese gecko with the Galo de Barcelos

👋 Hi Hélio

@HelioGuilherme66, I built your oculix branch on WSL Ubuntu 22.04 to chase the "OCR still fails" report, and I came back with one bug, one slowness, and an idea that makes both disappear. Spoiler: the idea deletes most of the repo.

🔍 Why OCR fails on Linux

Tesseract is not the culprit, it loads fine through Legerix. OpenCV is. The branch declares io.github.julienmerconsulting.apertix:opencv:4.10.0-0 directly in the pom, and Maven's nearest-wins rule lets it override the 4.10.0-3 that OculiX 3.0.3 brings. The 4.10.0-0 jar ships a single Linux native (libopencv_java490.so) and no legacy tier, so on any glibc below 2.38 the Java server logs FATAL: OpenCV native library 'opencv_java4100' could NOT be loaded. Removing those four lines from the pom is enough, OculiX already brings the right Apertix.

🐢 Why startup takes over a minute

Before the first keyword runs, Robot calls get_library_information, and javalib-core's KeywordBeanLoader answers it by opening the whole fat jar as a JarInputStream and reading every entry to find the classes matching keywords/**/*.class. A stream cannot skip an entry, so every OpenCV, Tesseract, Leptonica and JNA native of every platform gets inflated to find three classes. A thread dump caught it there after 45 seconds. I suspect #177 is a sibling of this one.

💡 The idea

OculiX already has a Python package on PyPI, oculix, which drives OculiX 4.0.0 directly. It needs no server and no port: the JVM runs as a child process, talks JSON over stdin/stdout, and dies with the Python process. Its jar is downloaded once into ~/.oculix/lib/ and then shared by everything on the machine.

SikuliLibrary would become a pure Python Robot library on top of it:

Today With oculix
XML-RPC remote server on a TCP port JVM child process over stdio, no port
Fat jar rebuilt by Maven at every release No build, the jar is downloaded once
Keyword discovery scans the whole jar Classes loaded on demand
Orphan JVMs when a run is interrupted JVM ends with the Python process
OculiX bump means pom, Apertix and Legerix OculiX bump means one version in install_requires

For users nothing changes: same pip install robotframework-SikuliLibrary, same Library SikuliLibrary, the same 76 keyword names and arguments. The Java sources, the pom and the assembly go away, and the wheel shrinks from a fat jar to a handful of .py files.

🛠️ How I would do it

I am coding it now and will open a PR against your oculix branch, written so that you can review it one file at a time. It will contain:

  • the 76 keywords in Python, with names, arguments and behaviour unchanged (timeouts, screenshots on failure, highlight);
  • oculix declared in install_requires;
  • a check at import that Java is on the PATH;
  • the Java tree and the Maven build removed.

The PR will link back here.

Muito obrigado, Hélio, por manteres esta biblioteca viva ao longo de todos estes anos. Um grande abraço!

The gecko has already packed the fat jar into a very small box. 🦎

Lenguaje dominante
Java
Estrellas
163
Forks
60
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MarketSquare/robotframework-SikuliLibrary

Todos los issues de MarketSquare/robotframework-SikuliLibrary

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.