2.7.0 Upgrade

.claude/agents/glsp-template-updater.md

@@ -0,0 +1,103 @@
+---
+name: glsp-template-updater
+description: Updates a single GLSP project-template to a target GLSP release. Bumps GLSP dependencies and the project's own version, applies changelog-driven migrations, syncs env/README prerequisites, and verifies via the template's own build. Spawned in parallel (one per template) by the update-project-templates skill.
+model: sonnet
+tools: Bash, Read, Edit, Write, WebFetch, WebSearch
+---
+
+# GLSP Template Updater
+
+You update **one** GLSP project-template to a target GLSP release. You are invoked
+by the `update-project-templates` orchestrator, which hands you a **release context**:
+
+- `targetVersion` — the GLSP release to update to (bare semver, e.g. `2.7.0`).
+- `templateId` — which template you own (e.g. `node-json-theia`).
+- `templatePath` — absolute path to that template.
+- `components` — the component subset relevant to this template.
+- `changelogUrls` — per-component changelog links from the umbrella release body.
+
+Read your template's entry in
+`.claude/skills/update-project-templates/references/templates.md` first — it lists the
+exact files to edit, the build command, and the relevant components.
+
+## Procedure
+
+1. **Verify the manifest against reality.** Confirm the files/dep-names/properties
+   listed for your template still exist. If anything has drifted (renamed packages,
+   moved poms, restructured target), **note it as a drift flag** and adapt — do not
+   blindly trust the manifest.
+
+2. **Probe the toolchain up front.** Your build needs specific tools (`yarn`/`node`
+   always; `mvn` + `java 17` for java templates; java/Tycho needs network access to
+   `download.eclipse.org`). Run quick probes (`yarn --version`, `node --version`,
+   `mvn --version`, `java -version`). **If a required tool is missing/unusable, STOP
+   immediately** — make no edits, return status `STOPPED` with the reason. A template
+   you cannot build is never reported as updated.
+
+3. **Bump GLSP dependencies** to `targetVersion` everywhere they appear in your
+   template (see manifest): npm `@eclipse-glsp/*` deps & devDeps, Maven `glsp.version`
+   property, and the p2 `releases/<version>` URLs in the target file. Use exact-pin
+   replacement (these are pinned, not ranged).
+
+4. **Bump the project's own version** in lockstep to `targetVersion`: root + every
+   workspace `package.json` `version`, `lerna.json` `version`, and pom `<version>`.
+   Do **not** touch unrelated third-party deps (webpack, lerna, typescript, theia,
+   etc.) unless a changelog explicitly requires it.
+
+5. **For `java-emf-eclipse` only:** in the `.target`/`.tpd`, update **only** the two
+   GLSP p2 `releases/<version>` URLs. Do **not** touch the Eclipse-platform / EMF /
+   Jetty / ELK / Jakarta versions and do **not** rename the `r20XX-YY` target — those
+   track the Eclipse release train, a separate concern. If a GLSP changelog says it
+   now requires a newer Eclipse/EMF baseline, **flag it for manual follow-up**.
+
+6. **Read your relevant changelog(s)** from `changelogUrls` (only the target
+   release's entry — examples update every release, so the gap is always one release).
+   Apply migrations:
+   - **Mechanical / unambiguous** (renamed exports, moved import paths, renamed
+     symbols): apply directly.
+   - **Judgment calls** (changed signatures, behavioral changes): make a best-effort
+     edit and record it as a **needs-review** item with the changelog reference.
+
+7. **Env updates (changelog-driven).** If the release raises the minimum **Node** or
+   **Java**, update **both** the source (`engines.node` in package.json /
+   `java.source`+`java.target` in poms) **and** the matching README prerequisite line,
+   keeping them consistent. Do **not** fix unrelated README staleness (e.g. old
+   `2023-09` Eclipse-train references, or a pre-existing Java-version mismatch) —
+   **flag** those instead. There is no GLSP version string in the READMEs to bump.
+
+8. **Verify via the template's own build, iterating until it passes.** Run the
+   template's root build (`yarn install && yarn build`, or `yarn prepare`) exactly as
+   listed in the manifest — never hand-craft or guess build commands. The build
+   regenerates any committed client bundles (e.g. `java-emf-eclipse`'s
+   `diagram/bundle.js`) as a side effect — that is expected.
+
+   **A failed build is the start of a fix loop, not a stopping point.** When it
+   fails:
+   - Read the actual compiler/build errors and trace them to a cause — most often a
+     migration you missed or got wrong (a renamed export, changed signature, removed
+     API), a dependency version that needs a coordinated bump, or a config/lint
+     change the release introduced.
+   - Apply a targeted fix and **re-run the build**. Repeat — diagnose → fix → rebuild
+     — until it passes. Re-check the relevant changelog whenever an error points at a
+     GLSP API you haven't accounted for.
+   - **Success = the build passes.** Only report `FAIL` after you have genuinely
+     exhausted reasonable fix attempts; then include the remaining error excerpt and
+     a short account of what you tried and why it's stuck. Distinguish this from
+     `STOPPED` (missing toolchain, no edits made).
+   - Anything you changed purely to make the build pass that involved judgment goes
+     into `needs-review`.
+
+9. **Do not run any git commands.** Leave all changes in the working tree.
+
+## Return a structured report
+
+Return (as your final message) a report for your template with these fields:
+
+- `templateId`, `from` → `to` version
+- `glspDepsBumped` — list/count of GLSP deps changed
+- `ownVersionBumped` — yes/no
+- `mechanicalMigrations` — what was applied
+- `needsReview` — judgment-call edits + Eclipse/EMF baseline flags, each with changelog ref
+- `envChanges` — Node/Java + README prerequisite edits made
+- `buildStatus` — `PASS` | `FAIL` (+ error excerpt) | `STOPPED` (+ missing toolchain)
+- `flags` — manifest drift / pre-existing inconsistencies noticed

.claude/skills/update-project-templates/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: update-project-templates
+description: Updates the GLSP project-templates in this repo to a new GLSP release. User-invoked only.
+disable-model-invocation: true
+---
+
+# Update Project Templates
+
+Updates this repo's 4 `project-templates/` to a target GLSP release. (The
+`workflow/` example has its own dedicated `update-workflow` skill — it is not a
+target here.)
+
+**Scope:** the 4 `project-templates/` — `node-json-theia`, `node-json-vscode`,
+`java-emf-eclipse`, `java-emf-theia`. See [references/templates.md](references/templates.md).
+
+**Optional argument:** an explicit target version (e.g. `2.7.0`). If omitted, the
+latest release is resolved automatically.
+
+## Phase 1 — Discovery (do this once, yourself)
+
+1. **Resolve the target version.** If the user passed an explicit version, use it
+   verbatim. Otherwise call the GitHub Releases API for the latest release of the
+   umbrella repo and strip any leading `v`:
+   `WebFetch https://api.github.com/repos/eclipse-glsp/glsp/releases/latest` → `tag_name`.
+   No npm cross-check.
+2. **Get the changelog links.** Fetch the umbrella **release body** (same API
+   response, `body` field). It contains links to the individual component repos'
+   changelogs. Extract them.
+3. **Assemble the release context**: `targetVersion`, the changelog URLs, and the
+   per-template component→repo map from [references/templates.md](references/templates.md).
+
+Only the **target release's** changelog matters — examples are updated every release,
+so the gap is always exactly one release. Do not compute a "from" version.
+
+## Phase 2 — Fan-out (4 parallel subagents)
+
+Spawn **4 `glsp-template-updater` subagents in parallel — one per template**, in a
+single message. Hand each the release context plus its `templateId`, `templatePath`,
+relevant `components`, and `changelogUrls`. Add any per-template note as extra
+instructions. The subagents edit + verify only; **they run no git commands**.
+
+Cross-cutting rules the subagents enforce (already in the agent definition, restated
+here so you can sanity-check their reports):
+- **Success = the template's own build passes.** A failed build triggers an
+  iterative diagnose→fix→rebuild loop in the subagent; `FAIL` is reported only after
+  reasonable fix attempts are exhausted, never after a single failed build.
+- **Stop a template entirely if its required toolchain is missing** (`mvn`/`java 17`
+  for java templates, `yarn`/`node` for all) — reported as `STOPPED`, no edits.
+- GLSP deps **and** the project's own version bump in lockstep to `targetVersion`;
+  unrelated third-party deps are left alone unless a changelog mandates a change.
+
+## Phase 3 — Synthesis (you)
+
+**Do no git operations.** Leave all changes in the working tree for the user to
+review and commit. Collect the per-template reports into one consolidated summary:
+
+- Top line: **N/4 built successfully**.
+- Per template: `from → to`, GLSP deps bumped, own-version bumped (y/n), mechanical
+  migrations applied, **needs-review** items (with changelog refs), env/README
+  changes, **build status** (`PASS` / `FAIL` + excerpt / `STOPPED` + missing tool).
+- A consolidated **flags** section: manifest drift, required Eclipse/EMF baseline
+  bumps, and pre-existing inconsistencies the subagents noticed.
+
+Make non-`PASS` builds and needs-review items impossible to miss.

.claude/skills/update-project-templates/references/templates.md

@@ -0,0 +1,87 @@
+# Project-Template Manifest
+
+Per-template static data for `update-project-templates`. Paths are relative to the repo
+root. **Verify each entry against the actual files before editing** and flag drift —
+this manifest can go stale if the repo is restructured.
+
+All GLSP deps and each project's own `version` are currently pinned in lockstep
+(`2.6.0` at time of writing). Bump both to the target version.
+
+---
+
+## `node-json-theia` — `project-templates/node-json-theia`
+
+-   **Build:** `yarn install && yarn build` (root `package.json`; also a `prepare`).
+-   **Toolchain:** node (`>=20`), yarn.
+-   **Components / changelogs:** `client`, `server-node`, `theia-integration`.
+-   **GLSP deps (npm, exact-pinned):**
+    -   root `package.json`: `@eclipse-glsp/config` (devDep)
+    -   `tasklist-glsp-client/package.json`: `@eclipse-glsp/client`
+    -   `tasklist-glsp-server/package.json`: `@eclipse-glsp/server` (devDep)
+    -   `tasklist-theia/package.json`: `@eclipse-glsp/*` (theia-integration etc.)
+-   **Own version:** root + `lerna.json` + every workspace `package.json`
+  (`tasklist-glsp-client`, `tasklist-glsp-server`, `tasklist-theia`,
+  `tasklist-browser-app`).
+-   **Env:** `engines.node` (root). README prerequisite: `Node.js >=20`.
+
+## `node-json-vscode` — `project-templates/node-json-vscode`
+
+-   **Build:** `yarn install && yarn build` (root `package.json`).
+-   **Toolchain:** node (`>=20`), yarn.
+-   **Components / changelogs:** `client`, `server-node`, `vscode-integration`.
+-   **GLSP deps (npm):**
+    -   root `package.json`: `@eclipse-glsp/config` (devDep)
+    -   `tasklist-glsp-client/package.json`: `@eclipse-glsp/client`
+    -   `tasklist-glsp-server/package.json`: `@eclipse-glsp/server`
+    -   `tasklist-vscode/webview/package.json`, `tasklist-vscode/extension/package.json`:
+    `@eclipse-glsp/*` (vscode-integration etc.)
+-   **Own version:** root + `lerna.json` + workspaces (`tasklist-glsp-server`,
+  `tasklist-glsp-client`, `tasklist-vscode/webview`, `tasklist-vscode/extension`).
+-   **Env:** `engines.node` (root). README prerequisite: `Node.js >=20`.
+
+## `java-emf-eclipse` — `project-templates/java-emf-eclipse`
+
+-   **Build:** `yarn install && yarn build` (root → `build:client` = yarn install of
+  `glsp-client`; `build:server` = `cd glsp-server && mvn --batch-mode clean verify`).
+  The client `prepare`/`copyClient` regenerates the committed
+  `glsp-server/org.eclipse.glsp.example.javaemf.editor/diagram/bundle.js` etc. — that
+  is expected output of a passing build.
+-   **Toolchain:** node, yarn, **`mvn` + Java 17**, network to `download.eclipse.org`
+  (Tycho resolves a p2 target platform).
+-   **Components / changelogs:** `client`, `eclipse-integration` (ide), java/emf server
+  (delivered via p2, not Maven coords).
+-   **GLSP version locations:**
+    -   TS client: `glsp-client/package.json` (+ `tasklist-glsp/`, `tasklist-eclipse/`,
+    and `@eclipse-glsp/config`).
+    -   **p2 target (GLSP-only edit):** `glsp-server/org.eclipse.glsp.example.javaemf.target/r2025-12.target`
+    **and** `.../r2025-12.tpd` — update **only** the two GLSP p2 release URLs:
+    `download.eclipse.org/glsp/server/p2/releases/<version>` and
+    `download.eclipse.org/glsp/ide/p2/releases/<version>/`.
+    -   **Do NOT** touch Eclipse-platform / EMF / Jetty / ELK / Jakarta unit versions or
+    rename the `r20XX-YY` target — Eclipse release train, separate concern. Flag any
+    required baseline bump.
+-   **Own version:** TS client `package.json`s + all poms `<version>`
+  (parent + `org.eclipse.glsp.example.javaemf.{server,editor,target}` poms).
+-   **Env:** `java.source`/`java.target` in poms (currently 17). README prerequisites:
+  `Node.js >=20`, `Java >=21` (note: README says 21 but poms compile 17 — pre-existing
+  mismatch; flag, do not silently "fix" as part of a GLSP update).
+
+## `java-emf-theia` — `project-templates/java-emf-theia`
+
+-   **Build:** `yarn install && yarn build` (root → `build:server` =
+  `cd glsp-server && mvn --batch-mode clean verify`; `build:client` = yarn install of
+  `glsp-client`).
+-   **Toolchain:** node, yarn, **`mvn` + Java 17** (Maven shade build, no p2/Tycho).
+-   **Components / changelogs:** `client`, `theia-integration`, java/emf server.
+-   **GLSP version locations:**
+    -   Maven: `glsp-server/pom.xml` → `<glsp.version>` property (drives the
+    `org.eclipse.glsp.*` artifacts).
+    -   TS client: `glsp-client/package.json` (+ `tasklist-glsp/`, `tasklist-theia/`,
+    `tasklist-browser-app/`, and `@eclipse-glsp/config`).
+-   **Own version:** TS client `package.json`s + `glsp-server/pom.xml` `<version>`.
+-   **Hardcoded server-jar filename** (`org.eclipse.glsp.example.javaemf-<version>-glsp.jar`,
+  not build-validated — bump in lockstep with the pom):
+    -   `glsp-client/tasklist-theia/src/node/glsp-server-contribution.ts` (`JAR_FILE`)
+    -   `glsp-server/.vscode/tasks.json` (`java -jar` task)
+-   **Env:** `java.source`/`java.target` (pom). README prerequisites: `Node.js >=20`,
+  `Java >=21` (same pre-existing 21-vs-17 mismatch; flag only).

.claude/skills/update-workflow/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: update-workflow
+description: Updates the GLSP workflow example in this repo to a new GLSP release by porting the release delta from the upstream dev examples. Interactive, human-in-the-loop. User-invoked only.
+disable-model-invocation: true
+---
+
+# Update Workflow Example
+
+Updates the `workflow/` example to a target GLSP release. This is **not** a trivial
+bump-and-fix: the `workflow/` example is a **condensed fork** of the upstream dev
+examples that live across the GLSP source repos. The job is to **port the release's
+delta** from those upstream dev examples into this condensed fork, then do the
+mechanical version bump.
+
+This skill runs **in the main agent, no subagent — interactively, with a checkpoint
+per target.** It involves real judgment; keep the human in the loop.
+
+**Optional argument:** an explicit target version (e.g. `2.7.0`). If omitted, the
+latest release is resolved automatically.
+
+See [references/workflow-mapping.md](references/workflow-mapping.md) for the
+target→upstream mapping, per-target filtering rules, and dependency order.
+
+## Phase 1 — Resolve version & acquire upstream sources
+
+1. **Resolve the target version:** explicit
+   arg wins, else GitHub Releases API on `eclipse-glsp/glsp`
+   (`https://api.github.com/repos/eclipse-glsp/glsp/releases/latest` → `tag_name`,
+   strip leading `v`). Also note the umbrella **release body** changelog links —
+   used as a secondary reference (below).
+2. **Shallow-clone the 3 upstream repos** at the release tag into a temp dir
+   (`/tmp/glsp-update-<version>/`): `glsp-client`, `glsp-server-node`,
+   `glsp-theia-integration`. Also fetch the **previous** release tag in each (needed
+   for the delta). Tag convention is `v<version>`; list tags and fall back to bare
+   `<version>` if needed. Clean up the temp dir on success; leave it on failure.
+
+## Phase 2 — Per-target porting (dependency order, checkpoint each)
+
+Process targets **in dependency order**: `workflow-glsp` → `workflow-server` →
+`workflow-theia` → `workflow-browser-app`. For **each** target:
+
+1. **Compute the release delta** in the upstream example:
+   `git diff <v_prev>..<v_new> -- <upstream example path>` (see mapping file). This
+   delta is the work-list — pre-existing condensation differences are not in it.
+2. **Classify each hunk** using the target's filtering rule (mapping file):
+   `PORT` (applies to shared code or the variant this fork keeps) /
+   `EXCLUDE` (scoped to a browser entry point or a connection variant this fork does
+   not have — record the reason) / `UNCERTAIN` (needs human judgment). Read the full
+   current upstream source only to adapt a hunk that doesn't map cleanly onto the
+   local structure, and consult the changelog to interpret ambiguous hunks.
+3. **Checkpoint — present the plan and pause for approval:** list what will be ported,
+   what is excluded and why, and every `UNCERTAIN` item with a recommendation. Wait
+   for the user to approve / adjust before editing.
+4. **Apply** the approved changes to the local target. Run a **scoped compile**
+   (e.g. `tsc -b` for that package) as an early signal. Then move to the next target.
+
+## Phase 3 — Mechanical bump (after the source-merge)
+
+After the source-merge, bump versions deterministically. The `workflow/` example is a
+yarn + lerna workspace (node only — no Maven/Java/p2 here). Apply all of:
+
+- **GLSP dependencies → target version, lockstep, exact-pinned** everywhere they
+  appear: every `@eclipse-glsp/*` dep and devDep across the root `package.json`
+  (`@eclipse-glsp/config`) and the four workspace `package.json`s — currently
+  `@eclipse-glsp/client` (`workflow-glsp`), `@eclipse-glsp/server` +
+  `@eclipse-glsp/layout-elk` (`workflow-server`), `@eclipse-glsp/theia-integration`
+  (`workflow-theia`). **Include any NEW `@eclipse-glsp/*` deps** the source-merge
+  introduced — set them to the target version too.
+- **Each package's own `version` → target version, lockstep:** root `package.json`,
+  `lerna.json`, and all four workspace `package.json`s (`@eclipse-glsp-examples/*`).
+  Note the workspaces also reference each other by version (e.g. `workflow-theia`
+  depends on `workflow-glsp`/`workflow-server`) — bump those inter-package refs too.
+- **Leave unrelated third-party deps alone** (theia, webpack, lerna, typescript,
+  `@types/node`, …) unless a changelog explicitly mandates a change.
+- **Env / README:** if the changelog raises the minimum **Node**, update both
+  `engines.node` (root `package.json`) and the matching README prerequisite line,
+  keeping them consistent. Flag other README staleness rather than editing it.
+
+## Phase 4 — Final build & report
+
+1. **Authoritative gate:** full root `yarn install && yarn build` (the `prepare` step
+   also runs `check:theia-version`). Use the **iterative diagnose→fix→rebuild loop**;
+   a failed build is the start of a fix loop, not a stop. Because this is
+   human-in-the-loop, **escalate genuinely ambiguous failures to the user** instead of
+   looping blindly. `STOPPED` only if the toolchain (node/yarn) is unavailable.
+   **Success = the full build passes.**
+2. **No git operations** — leave everything in the working tree for the user to review
+   and commit. Produce a report: per target — hunks ported, hunks excluded (+reason),
+   `UNCERTAIN` items and how they were resolved; version/env/README bumps; final build
+   status; and the temp-clone path (note if it was left behind on failure).