[Feature]: Decide fate of AutoUpdater — currently dead code since OculiX fork

[julienmerconsulting]

Problem / motivation

While running an i18n audit on IDE/src/main/java/ for the v3.0.5 release I noticed that org.sikuli.ide.AutoUpdater has two hardcoded EN buttons (new JButton("ok") line 212, new JButton("download") line 233). Before fixing them I went to verify they were even reachable — and they are not.

AutoUpdater has been a no-op since the OculiX fork. A quick autopsy:

Indice	Preuve dans le code
Class marked TODO from line 1	public class AutoUpdater { //TODO
Main update-check loop entirely commented out	AutoUpdater.java:75-120 — // for (String s : SikulixIDE.runTime.ServerList) { ... }
checkUpdate() therefore always returns 0 (= "nothing to update")	available is never incremented
Auto-call at IDE start is commented too	Sikulix.java:101 — //TODO autoCheckUpdate();
Hardcoded fallback URLs are dead	// DOWNLOAD https://launchpad.net/sikuli/+download (Launchpad abandoned ~2014) + // BETA https://dl.dropboxusercontent.com/u/42895525/... (personal Dropbox, gone)
The matching i18n key reflects this	prefMoreUpdateNotImplemented=Check for Updates (not yet implemented) (and it's an orphan — referenced by no Java code)

Net effect today: clicking Help → Check for Updates runs doCheckUpdate(), which calls au.checkUpdate() → returns 0 → shows msgNoUpdate or msgUpdateError. The showUpdateFrame() with its two unlocalized buttons is therefore never rendered to any user.

So I have a decision to take before v3.0.5 ships, and rather than take it alone on a piece of code I didn't write, I'd like @RaiMan's read.

Proposed solution

Three options, in increasing effort:

Option A — delete AutoUpdater entirely

• Remove the class, the Help → Check for Updates menu item, the matching PreferencesUser.getCheckUpdate() field, and the orphan i18n keys (prefMoreUpdateNotImplemented, dlgUpdateAvailable, msgUpdate, msgUpdateError, msgNoUpdate, menuHelpCheckUpdate).
• Smallest API change, clearest signal to users.
• Loss: no in-IDE update mechanism at all — users find releases via GitHub or Sonatype only.

Option B — replace with a thin GitHub Releases check

• Rewrite checkUpdate() to call https://api.github.com/repos/oculix-org/Oculix/releases/latest, compare against Commons.getSXVersionIDE(), and show a notification linking to the release page.
• Keep the menu item, keep the i18n keys, just point at a live data source.
• ~50 lines of code (one HttpURLConnection + JSON parse on tag_name). No new dependency if we use org.json already on classpath, otherwise regex out "tag_name":"vX.Y.Z".
• Side benefit: makes prefMoreUpdateNotImplemented finally honest, can be removed.

Option C — resurrect the original Launchpad/Dropbox flow

• Just un-comment the loop and point it at a new server we control.
• Functionally similar to B but requires hosting the metadata ourselves (release index file). Won't suggest this unless there's a reason A and B don't work.

Alternatives considered

Status quo (do nothing). Acceptable but leaves dead code in the IDE, a menu item that lies to users ("Check for Updates" → "no updates" forever), and two hardcoded EN strings in a frame that exists only on paper. Build hygiene argues against this.

Defer to v3.1.0. Also fine if there's bigger fish to fry for v3.0.5 — I just don't want to silently i18n strings that will never render.

Where would this live?

IDE (editor, menus, dialogs, recorder)

API impact

Option A → Yes — modifies existing API (potentially breaking) — removes the Check for Updates menu item and a PreferencesUser field.
Option B → No — internal / non-breaking addition — same surface, different implementation.
Option C → No — internal / non-breaking addition.

Use case / impact

v3.0.5 release prep. With ~150 companies now adopting OculiX in production (per Scarf telemetry), an actual update mechanism — even just a "new release available, open page?" notification — has real value: today a v3.0.3-pinned user has no way of learning that v3.0.5 ships a fix for their open ticket without manually checking the repo.

Lower-priority but real: clean dead code is easier to audit during security reviews, which matter for the F500/Defense tier of the adopter list.

Additional context

@RaiMan — this is a piece you wrote and it's been parked since well before the fork. Three honest questions:

1. Do you remember why the loop was originally commented out? (Server-side decommissioning? Beta-channel rework that never landed? Something else?) Context would help us pick between A / B / C without re-treading old ground.
2. Option B (GitHub Releases API) — does that direction sit OK with you, or do you see a reason to keep the update mechanism off the IDE entirely (e.g. enterprise users behind air-gapped networks where any outbound HTTP is unwelcome)?
3. If you'd rather we just delete the whole machinery (Option A), say the word — your call on your code.

No rush on the answer — v3.0.5 can ship either way (with the deletion, with B implemented, or with the menu hidden and a follow-up issue). Just want to make sure we don't quietly remove a piece without checking with you first.

I'm asking now in particular because I noticed fd45d843 ("ExtensionManager removed for now — parked in Support") and read it as a coherent cleanup moment on parked-but-still-wired code. AutoUpdater feels like it's in the same bucket. If you'd rather batch the decision with whatever you're doing on the new Extension concept, that's also fine — just say "later".

[RaiMan]

@julienmerconsulting

Simple decision: completely remove it.

The world has changed since then: For open source software that lives on GitHub, the information bias and how to get new versions is GitHub. The history of SikuliX in this area is some legacy from the founders.

The extension stuff is different: how it will be setup and implemented in the future is an open question.

[julienmerconsulting]

@RaiMan — thanks for the clear position. I want to land on a different conclusion, after running a proper analysis of where OculiX actually lives today. Here's what I found and what I'm going to do.

📊 OculiX doesn't live on one canal — it lives on at least four

Pulled directly from each registry's authoritative endpoint, no Sonatype web UI cache:

Canal	Status	Concrete role
GitHub Releases	✅ active (oculix-org/Oculix)	source of the announcement — changelog, tags, signed releases
Maven Central (Sonatype)	✅ 5 artifacts vivants	source of the versioned binary for anyone consuming the Java
SourceForge	✅ project page exists (sourceforge.net/projects/oculix/)	bridge for users who still know SikuliX1 through that historical entry point
Maven CN mirrors (Aliyun, Huawei, JFrog APAC)	✅ mirrored automatically	makes OculiX reachable in China without us configuring anything — they reflect repo.maven.apache.org transparently

Maven Central numbers (read live from maven-metadata.xml):

Artifact	Latest	Versions published
io.github.oculix-org:oculixide	3.0.4	5 (3.0.1 → 3.0.4)
io.github.oculix-org:oculixapi	3.0.4	5
io.github.oculix-org:oculixmcp	3.0.4	4
io.github.oculix-org:oculix	3.0.4	5
io.github.julienmerconsulting:legerix	5.5.0-8	8

OculiX is not a single-canal artifact. Removing The SikuliX Updater removes the only mechanism that serves one specific audience (see below), while the other three audiences keep their own update path.

👥 Four audiences, four update paths — The SikuliX Updater serves exactly one

Audience	How they currently get updates	In-app updater useful?
Devs consuming the Java lib (oculixapi as a Maven/Gradle dep)	their build tool — mvn versions:display-dependency-updates, Dependabot, Renovate	❌ already handled by their toolchain
Users in China (corporate Java behind a great-firewall-aware Nexus / Aliyun mirror)	transparent through their settings.xml mirror	❌ handled by mirror transparency
Legacy SikuliX1 users who still land on SourceForge	manual download from the project page	❌ outside any auto-updater scope, by definition
Desktop IDE users — QA engineers, RPA practitioners, non-Java people who download the JAR and double-click	nothing today — they have to remember to come check the repo	✅ this is the audience The SikuliX Updater exists for

The desktop IDE audience is the polish-conscious one, the one that compares us to VS Code / IntelliJ / Slack — products that all ship their own named updater (Squirrel for Electron, Sparkle for macOS apps, JetBrains Toolbox for IntelliJ) because their users expect that affordance. The SikuliX Updater is the same kind of component, with its original SikuliX1 name kept on purpose — same continuity logic that has the Java packages still living under org.sikuli.*.

🛠️ Concrete design — The SikuliX Updater (name preserved)

Same external surface as today (Help menu entry + Preferences checkbox), rewritten on top of the canals that actually exist:

1. Detection — GET https://repo.maven.apache.org/maven2/io/github/oculix-org/oculixide/maven-metadata.xml

   • Lighter than the GitHub Releases JSON, no rate limit, already whitelisted by every F500 firewall (any Java shop reaches Maven Central)
   • Picks up the Aliyun / Huawei / JFrog mirrors transparently for China-based users via their local settings.xml
   • Compare <release> against Commons.getSXVersionIDE()

2. Announcement — fetch the release notes from GitHub Releases API (only on user confirm, so the firewall-restricted case still works in degraded mode)

3. Download — pull the IDE distribution ZIP from the GitHub Releases asset (because Maven Central ships the JAR, but the desktop pack also ships the launcher / icons / locale resources). Verify SHA against the .sha1 companion on Maven.

4. Reinstall — write ~/.OculiX/update.pending, the launcher (.bat / .sh) swaps before the JVM boots on next launch. Either a hand-rolled bootstrap or Update4j.

5. Opt-in by default off — F500 / regulated / air-gapped environments must never see the IDE phone home without explicit consent. The checkbox is in Preferences, default unchecked.

🤝 The founders' design wasn't obsolete — its data sources were

I don't read the existing AutoUpdater skeleton as something to discard. The original SikuliX design was the right concept; it just lost its data sources over the years (the dead Launchpad URL, the personal Dropbox link). The shape was correct. The SikuliX Updater is the same shape — same name kept on purpose — modernized only where 2026 forces it: Maven Central and GitHub Releases as data sources instead of the dead ones.

So the plan is: keep the concept the founders got right, modernize what 2026 has changed under it.

🦎 Next steps

I'll do this in the same granular-commit style as the rest of the recent work (1 file = 1 commit), branched on claude/i18n-phase3, kept opt-in OFF by default. If you spot an angle I missed — especially on the Windows JAR-swap nuance, which is the trickiest part of the implementation — happy to hear it before I start.

@adriancostin6 — your read welcome too, especially on the desktop IDE audience experience.

[adriancostin6]

@julienmerconsulting only way I consumed the Oculix artifacts so far has been through the Github releases page.

That being said, I love the analysis above and the fact that you narrowed down a group of users that will benefit from an updater. I think the opt-in by default off is a sane approach, as you stated (explicit consent).

The outlined steps sound great. I would gladly test this if we decide on going forth with it.

[RaiMan]

@julienmerconsulting
I am always overwhelmed (positive) by your epic answers on my short statements.

So since I really have a different opinion about an autoupdater, it needs more from my side.

In fact, we are only talking about the IDE, since with its UI it comes a bit nearer to be an application.
But still it is only a jar, that you somehow have to integrate into your personal environment.
From Oculix’s view it is still more complicated, since it has to look at Windows, Linux and Mac.

So in the first place it is ok, to notify the user, that a new version is available:

• a popup the first 1 -3 starts of the IDE after the update date (e.g. integrated with the preflight picture)
• after that a sticky note near the version info „update available“
• a click on that note or the popup reveals more information, where and how to get it
• it might be also available by a menu entry (check for updates) or in the about note

Additionally it might be ok, to offer some download support.

But a reinstall support is oversized:

• you need information about, where on the system the old jar (or even more than one) lives
• the user might have his own environment, where the jar is mentioned
• the jar itself in its name has its version, not only inside as setting (like apps do it)

Conclusion: A real autoupdater is not needed in the current situation.
The effort to be put into it now and in the future can be better put elsewhere.

[julienmerconsulting]

@RaiMan — taking position on your design, point by point, plus one missing piece that I think buries the "reinstall" question for good.

✅ Full agreement on notify-only

Popup on the first 1–3 starts after an update is detected, then a sticky note near the version info, a Check for updates menu entry, and download support. No reinstall machinery — you are right that it is oversized, and below is why we will never need it.

📡 Channel policy for the startup check

Channel	Behavior
Stable releases	The startup check notifies on these — default and only automatic channel
RCs	If an RC newer than the latest stable exists, it is offered as an explicit choice (in the update dialog / menu entry) — never pushed. Nobody should discover at startup that their production register now runs a release candidate.

🔁 The missing piece: the old jar becomes a forwarder

Your objection to reinstall was "you need information about where on the system the old jar lives". There is a way to not need it: the jar knows where it lives — it's there.

At startup, before the splash, the jar looks in its own folder for a sibling carrying a higher version number in its filename (oculixide-X.Y.Z*.jar — semantic compare on the parsed version, never on file dates: timestamps lie, filenames don't). Three cases:

• Newer sibling found → it launches it and says: "This version is obsolete — OculiX now opens X.Y.Z, please use it next time instead." The user can keep double-clicking their old shortcut forever; they always land on the right version.
• No sibling → it says nothing and goes on with its life.
• Unparseable filenames (renamed jar, exotic suffix) → same: silence, normal startup. When in doubt, do nothing.

Guards: the launched sibling gets a --no-forward marker (no loops); in CLI mode (-r etc.) all args are forwarded and the popup is replaced by a console line — which quietly means a runner farm pointing at an old jar survives upgrades without editing a single path.

Combined with your notify + download (which drops the new jar next to the old one), the lifecycle closes itself: notify → download → forward. Nothing to uninstall, nothing to move, nothing to know.

If this shape works for you, I'll take the implementation. 🦎

[RaiMan]

@julienmerconsulting
Still not convinced, that we need more than some notification service about new versions (also as messages in the CLI output) and at least a link to a web page that has infos about the new version and and an option to download the needed jar variants.
What to do with the downloads and how to deal with the old versions is totally up to the user.

As already mentioned, this might look different, if Oculix in the future becomes a regular app in the relevant eco systems of the system variants.

So at this point I am out and leave the decision on more or extended features in this context up to you.