Skip to content

fix(project-bin/_common.sh): match Studio Pro and JDK discovery to the model - #145

Draft
MendixMau wants to merge 1 commit into
masterfrom
fix/discovery-sp-version-and-jdk
Draft

MendixMau wants to merge 1 commit into
masterfrom
fix/discovery-sp-version-and-jdk

Conversation

@MendixMau

Copy link
Copy Markdown
Owner

Lane: Direct

What changed and why (one paragraph)

A colleague's doctor.sh run on a Mac with several Studio Pro versions installed surfaced two discovery defects. find_sp_app always took the highest-versioned root (sort -V | tail -1), never the one matching the model, so an older project built against a newer Studio Pro's mxbuild. find_java accepted the first directory that existed with no check that it was a JDK, so a 32-bit JRE 8 was returned while JDK 21 sat unused. Now find_sp_app reads the model's own Mendix version from the .mpr (new project_mendix_version: _MetaData._ProductVersion via SQLite through the existing resolve_py, with a self-verifying strings fallback that refuses to guess on the doubled-blob layout) and prefers the matching install when more than one exists, falling back to newest with a named WARNING:. A single install stays a no-op. find_java requires bin/javac (_mtk_has_javac) from the Studio Pro tier onward, probes well-known JDK roots per platform before PATH, prefers JDK 21 for a Mendix 11.x model (the only mapping the repo documents), and explains any guess on stderr. bin/doctor.sh captures that stderr through a small doctor_find helper and prints it as notes, so the report says why a root was chosen, not only which. MENDIX_APP and JAVA_HOME still win unconditionally.

Addresses items 1 and 3 of the doctor.sh false-alarm table from the field (item 2, the gate self-test scratch copy, is #142).

Field evidence

  • project_mendix_version verified against a real Mendix 11.12.1 .mpr (SQLite schema _MetaData with _FormatVersion, _ProductVersion, _BuildVersion, _SchemaHash); the strings fallback returns the same value and returns failure, not a wrong answer, on the doubled blob.
  • Multi-install and multi-JDK behaviour exercised on fake fixture trees on Linux; JDK 21 preferred over a javac-less JRE 8 directory.
  • bash -n clean; bin/check-portability.sh clean (163 files); leak guard clean.
  • Not run on a real macOS or Windows box. The /usr/libexec/java_home, /Applications, and Program Files branches were exercised by env-var simulation only. Needs one field run on the reporting colleague's Mac before merge.
  • Open question for that run: Studio Pro's bundled runtime is now skipped when it lacks javac. If a real Mac Studio Pro bundle ships a JRE and mxbuild was working with it, the tier order falls through to the well-known JDK roots, which is a behaviour change worth confirming (the comment at doctor.sh line ~641 still describes the old policy).

Checklist

  • No client data (names, paths, hostnames) in the diff or this description
  • Size cap: 3 files, +246/-13 excluding CHANGELOG
  • Test tier: T1 (syntax, guards, fixture trees on Linux); T2 field run pending
  • Instrument rules: no new artifact consumer; both functions keep their old fallback when the version cannot be read
  • Routing row: n/a (no skill change)
  • CHANGELOG line appended under ## Unreleased
  • Bug entry: n/a

🤖 Generated with Claude Code

https://claude.ai/code/session_01VJgWP5vEoAsNsJYqCDMGNw


Generated by Claude Code

…e model

find_sp_app used to sort -V | tail -1 over every installed Studio Pro root and
always take the highest-versioned one, ignoring the model's own Mendix
version unless MENDIX_APP was set by hand. With more than one root found, it
now reads the model's version from the .mpr (new project_mendix_version:
SQLite via the existing resolve_py, with a self-verifying `strings` fallback
for a Python-less machine — the model's _ProductVersion/_BuildVersion are
adjacent TEXT columns that land in `strings` output as one doubled blob, so
the fallback only trusts a candidate that really is two identical halves)
and prefers the matching install, falling back to newest-installed with a
named WARNING only when nothing matches. find_sp_app takes an optional
<mpr-path> argument (every existing caller omits it and gets find_mpr()'s
own resolution); MENDIX_APP still wins unconditionally before any of this
runs.

find_java accepted the first directory that merely existed, with no check
that it was a JDK and not a JRE, so a 32-bit JRE 8 with no javac could be
returned while a real JDK sat unused elsewhere. Every tier from Studio
Pro's bundled runtime onward now requires bin/javac (new _mtk_has_javac);
JAVA_HOME still wins first but warns if it lacks javac. A new well-known-
JDK-roots tier is probed before the final PATH fallback (macOS
/Library/Java/JavaVirtualMachines, Windows Eclipse Adoptium/Java/Microsoft
install dirs under Program Files, Linux /usr/lib/jvm), preferring JDK 21
for a Mendix 11.x model — the only Mendix-version-to-JDK mapping this repo
documents (skills/testing-shape.md, doctor.sh's own messages) — and saying
so (WARNING/NOTE) whenever it has to fall back or guess.

bin/doctor.sh now captures find_sp_app/find_java's stderr reasoning (via a
new doctor_find helper, one invocation each) and prints it as report notes,
so the report says which Studio Pro root and JDK were chosen and WHY, not
just which.

Verified: real Mendix 11.12.1 .mpr schema (_MetaData._ProductVersion)
confirmed by direct sqlite3 inspection; project_mendix_version's Python and
strings-fallback tiers both verified against it and against a synthetic
non-doubled file (correctly refuses rather than guessing); find_sp_app and
find_java verified end-to-end (including through find_mxbuild/find_java_exe,
called exactly as every real caller calls them) against fake multi-Studio-
Pro and multi-JDK fixtures via env-var simulation, and against this Linux
sandbox's own JDK 21 for the PATH tier. The macOS java_home/Applications
and Windows Program Files branches are exercised only by env-var
simulation here, never a real Mac or Windows machine — field run needed.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VJgWP5vEoAsNsJYqCDMGNw
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant