chore: dirigible 14.18.0, the Monitoring shell, and the HANA scan gap

[delchev]

Retargets Gaia from 14.14.0 to 14.18.0, adapts the edition to what the four releases in between removed or renamed, and adds the new Monitoring shell with the backends its pages read.

1. Pin to 14.18.0

Olingo dropped. dirigible-dependencies no longer manages com.codbex.olingo:olingo-odata2-lib — OData was extracted from the platform in 14.16.0 (eclipse-dirigible/dirigible#6604). A version-less declaration then fails at model-read time, so the build cannot even reach code-style. Nothing in the Gaia dependency set uses OData, so the declaration goes.

The AngularJS Dashboard shell is retired. resources-dashboard was removed in 14.18.0 (eclipse-dirigible/dirigible#6620), so the dependency no longer resolves — and DIRIGIBLE_HOME_URL=services/web/dashboard/ aimed / at a 404. Home is now the Home launchpad, which Gaia already ships (resources-home) and which is the platform default. The twelve application-* extension points the Dashboard used to declare moved to resources-application, which Gaia also ships, so the help menu's application-menus contribution keeps resolving.

"My Work" became "Personal" — resources-my → resources-personal, /services/web/my/ → /services/web/personal/ (eclipse-dirigible/dirigible#6612).

The forked help menu's translations were dead. locales.js scans <module>/i18n/<locale>/ only; this fork had drifted to translations/, so neither the English nor the Bulgarian catalog was ever served and the menu fell back to its hard-coded labels. Renamed to i18n/, matching upstream.

The AngularJS/TS application templates and template-form-builder-angularjs also went away in 14.16.0, but Gaia names no templates individually and pulls no template group, so it needs no change there.

2. The Monitoring shell

The operations surface at /services/web/monitoring/ — health, artefacts in error, failed jobs, process incidents, the JVM snapshot, the live log stream and the broker's queues — without opening a Web IDE this edition does not ship. Pure Harmonia over the shared application-core runtime, gated to ADMINISTRATOR / OPERATOR / DEVELOPER, and it registers itself in platform-shells, so it shows up in the Home launchpad and in every shell's user-menu switcher.

Its Overview, Jobs and Processes pages read core-healthcheck, core-base's artefact inventory, engine-jobs and engine-bpm-flowable — all already bundled. The three that were missing are added alongside the shell as one block, so the capability stays a single edit: ide-monitoring (JVM counts/metrics/threads), ide-logs (the log files) and ide-messaging-monitoring (the broker summary and queue browse, over the engine-listeners broker bean).

Two pieces are less obvious and are commented where they land:

• The bpmn-visualization webjar. The Processes page renders the live BPMN diagram with the same visualizer the IDE uses, loading it version-less from /webjars/. Upstream supplies it through ui-perspective-processes — Web IDE content this edition does not bundle — so it is declared here directly.
• org.eclipse.dirigible.commons joins the component scan. The Logs page's live stream is the platform logging appender's socket at /websockets/ide/console, published by ConsoleWebsocketConfig. That class sits in org.eclipse.dirigible.commons and is the only Spring bean under modules/commons, so naming the package picks up exactly that one config. Upstream gets it for free because its application class sits in org.eclipse.dirigible and scans the whole tree; this edition names its packages, so it has to name that one too.

Verification

Built the fat jar and booted it.

Classpath — 136 dirigible-* jars, all at 14.18.0; none of odata / olingo / angular / dashboard / resources-my. The monitoring commit adds exactly five artifacts and drags nothing in behind them: resources-monitoring, ide-monitoring, ide-logs, ide-messaging-monitoring, bpmn-visualization-0.47.0.

Runtime

• / → 302 → /services/web/home/ (200)
• platform-shells lists applicationShell, personalShell, partnerShell, adminShell, monitoringShell; each serves 200, as do inbox and documents; /services/web/{dashboard,my}/ correctly 404
• the menu-help namespace resolves through locales.js
• all eleven endpoints ops.js reads answer 200 with real payloads — metrics with runtime/cpu/memory/threads/gc, a live broker summary, three log files, 75 artefacts
• the version-less /webjars/bpmn-visualization/dist/bpmn-visualization.min.js serves the 981 KB library
• /websockets/ide/console completes the handshake with 101 Switching Protocols

Build — mvn install -P unit-tests green (the GaiaApplicationTest context loads), formatter:validate green, boot log free of ERROR.

Still out

resources-builder — the conversational intent builder — needs engine-intent, which this edition does not bundle.

🤖 Generated with Claude Code

3. The HANA connection beans were never registered

Found while investigating why the console socket was missing — same root cause, wider blast radius.

This edition ships dirigible-database-sql-hana, but two of that module's Spring beans sit in org.eclipse.dirigible.database.sql.dialects.hana, outside every package the application scanned:

• HanaConnectionEnhancer propagates the end user to HANA as APPLICATIONUSER / XS_APPLICATIONUSER client info on every connection. Without it, all database activity reaches HANA with no application user attached.
• HanaDatabaseConfigurator sets the HANA validation query (SELECT 1 FROM DUMMY) and a 5-minute Hikari keepalive. Without it, stale pooled connections are neither validated nor refreshed.

Both are consumed as plain List<T> constructor intakes, so their absence raised nothing — the lists just came back one element shorter. The dialect always worked, because it is published through META-INF/services/…ISqlDialectProvider and loaded by ServiceLoader rather than Spring; that is exactly why the gap stayed invisible.

Adding org.eclipse.dirigible.database to the scan is the whole fix. Blast radius is precisely those two classes — they are the only Spring stereotypes anywhere under modules/database — and the jar carries no AutoConfiguration.imports or spring.factories, so component scan is the only path by which they could register.

Verified on the booted jar via /actuator/beans: hanaConnectionEnhancer, hanaDatabaseConfigurator and consoleWebsocketConfig all registered, and each SPI now lists both implementations (hana* alongside snowflake*) rather than only the Snowflake one.

Reported upstream as eclipse-dirigible/dirigible#6635 — every distribution that names its scan packages has this gap, so the other editions are worth the same check.