jdt_move_type: Änderungen werden nicht auf Disk geschrieben #79

New issue

Open

opened 2026-04-10 07:11:03 +00:00 by hauschel.fred · 1 comment

hauschel.fred commented

2026-04-10 07:11:03 +00:00

Collaborator

Problem

jdt_move_type meldet SUCCESS, aber die Änderungen landen nicht auf dem Filesystem. Das Refactoring findet nur im In-Memory-Buffer statt.

Reproduktion

jdt_move_type({
  typeName: "de.g4ch.cg.activitypub.vocab.VocabAs",
  targetPackage: "de.g4ch.cg.shared.vocab",
  updateReferences: true,
  preview: false
})

Rückgabe: {"status": "SUCCESS", "newLocation": "de.g4ch.cg.shared.vocab.VocabAs"}

Tatsächliches Ergebnis auf Disk:

Quelldatei existiert noch, Package-Deklaration unverändert
Zieldatei wurde NICHT erstellt
Nur 1 von 85 Import-Updates wurde auf Disk geschrieben

Ursache

Change.perform() schreibt im Headless-Mode in den ITextFileBufferManager In-Memory-Buffer. Ohne Eclipse UI fehlt der automatische Save.

Bisheriger Fix-Versuch (Problem 3)

In RefactoringSupport.performChange() wurde ein expliziter Flush implementiert:

Betroffene IFiles aus dem Change-Tree sammeln
ICompilationUnit.hasUnsavedChanges() prüfen
cu.save() aufrufen
refreshLocal() auf betroffene Projekte

Dieser Fix greift nicht zuverlässig. Mögliche Ursachen:

Der Flush-Codepfad wird nicht für alle CUs erreicht
Die Quelldatei (Move-Source) wird von einem anderen Codepfad behandelt als die Import-Updates
hasUnsavedChanges() liefert false obwohl der Buffer dirty ist

Nächster Schritt

Log-Output in RefactoringSupport.performChange() hinzufügen, um zu prüfen:

Welche CUs werden als "unsaved" erkannt?
Wird der Flush-Codepfad überhaupt erreicht?
Was passiert mit der Quelldatei (die verschoben werden soll)?

Kontext

Reproduziert in zwei unabhängigen Sessions (ActorId, VocabAs) mit identischem Verhalten — jeweils genau 1 von ~85 Dateien auf Disk aktualisiert. Siehe agent_communication.md (Problem 3 + Problem 5).

## Problem `jdt_move_type` meldet `SUCCESS`, aber die Änderungen landen nicht auf dem Filesystem. Das Refactoring findet nur im In-Memory-Buffer statt. ## Reproduktion ``` jdt_move_type({ typeName: "de.g4ch.cg.activitypub.vocab.VocabAs", targetPackage: "de.g4ch.cg.shared.vocab", updateReferences: true, preview: false }) ``` **Rückgabe:** `{"status": "SUCCESS", "newLocation": "de.g4ch.cg.shared.vocab.VocabAs"}` **Tatsächliches Ergebnis auf Disk:** - Quelldatei existiert noch, Package-Deklaration unverändert - Zieldatei wurde NICHT erstellt - Nur 1 von 85 Import-Updates wurde auf Disk geschrieben ## Ursache `Change.perform()` schreibt im Headless-Mode in den `ITextFileBufferManager` In-Memory-Buffer. Ohne Eclipse UI fehlt der automatische Save. ## Bisheriger Fix-Versuch (Problem 3) In `RefactoringSupport.performChange()` wurde ein expliziter Flush implementiert: 1. Betroffene `IFile`s aus dem Change-Tree sammeln 2. `ICompilationUnit.hasUnsavedChanges()` prüfen 3. `cu.save()` aufrufen 4. `refreshLocal()` auf betroffene Projekte **Dieser Fix greift nicht zuverlässig.** Mögliche Ursachen: - Der Flush-Codepfad wird nicht für alle CUs erreicht - Die Quelldatei (Move-Source) wird von einem anderen Codepfad behandelt als die Import-Updates - `hasUnsavedChanges()` liefert `false` obwohl der Buffer dirty ist ## Nächster Schritt Log-Output in `RefactoringSupport.performChange()` hinzufügen, um zu prüfen: - Welche CUs werden als "unsaved" erkannt? - Wird der Flush-Codepfad überhaupt erreicht? - Was passiert mit der Quelldatei (die verschoben werden soll)? ## Kontext Reproduziert in zwei unabhängigen Sessions (ActorId, VocabAs) mit identischem Verhalten — jeweils genau 1 von ~85 Dateien auf Disk aktualisiert. Siehe `agent_communication.md` (Problem 3 + Problem 5).

fred referenced this issue from a commit

2026-07-07 15:32:33 +00:00

fix(refactoring): rework cross-module move_type + serialize mutations (#79)

hauschel.fred commented

2026-07-07 16:37:28 +00:00

Author

Collaborator

Umbau-Versuch auf Branch `fix/79-move-type-cross-module`

Ein weiterer Fix-Versuch liegt isoliert auf Branch fix/79-move-type-cross-module (gepusht). Er kompiliert sauber (mvn clean compile), die Disk-Schreib-Ursache ist aber noch nicht verifiziert.

Was der Branch ändert

move_type: MoveDescriptor → interne JavaMoveProcessor-API (voller Workspace-Scope für Referenzsuche); neuer targetProject-Param für Cross-Modul-Moves; Heartbeat gegen MCP-Timeout bei großen Moves.
RefactoringSupport.performChange(): globaler WORKSPACE_MUTATION_LOCK, Headless-AssertionFailedException-Handling, Reflection-basierte Fallbacks (manueller File-Move + manueller TextEdit-Apply) für MoveCompilationUnitChange.
Alle Refactorings laufen jetzt über performChange; MANIFEST.MF + org.eclipse.core.filebuffers.

Status / offen

⚠️ Noch nicht mergen. Ob jetzt tatsächlich alle ~85 Dateien auf Disk landen, ist ungeprüft. Nächster Schritt: End-to-End-Verifikation gegen tests/fixtures/fixture-external — Quelle gelöscht, Zieldatei erstellt, alle Import-Updates auf Disk. Erst grün → PR nach main.

Die eigenständigen Nebenfixes dieser Session (mcpServers-Wrapper, OSGi-Version, Throwable-Catch, self-healing Nav-Errors + Index-Probe, Maven-Dep-Rewire, Launcher-Recovery) sind bereits auf main.

## Umbau-Versuch auf Branch `fix/79-move-type-cross-module` Ein weiterer Fix-Versuch liegt isoliert auf Branch `fix/79-move-type-cross-module` (gepusht). Er **kompiliert sauber** (`mvn clean compile`), die Disk-Schreib-Ursache ist aber **noch nicht verifiziert**. ### Was der Branch ändert - `move_type`: `MoveDescriptor` → interne `JavaMoveProcessor`-API (voller Workspace-Scope für Referenzsuche); neuer `targetProject`-Param für Cross-Modul-Moves; Heartbeat gegen MCP-Timeout bei großen Moves. - `RefactoringSupport.performChange()`: globaler `WORKSPACE_MUTATION_LOCK`, Headless-`AssertionFailedException`-Handling, Reflection-basierte Fallbacks (manueller File-Move + manueller `TextEdit`-Apply) für `MoveCompilationUnitChange`. - Alle Refactorings laufen jetzt über `performChange`; `MANIFEST.MF` + `org.eclipse.core.filebuffers`. ### Status / offen ⚠️ **Noch nicht mergen.** Ob jetzt tatsächlich alle ~85 Dateien auf Disk landen, ist ungeprüft. Nächster Schritt: End-to-End-Verifikation gegen `tests/fixtures/fixture-external` — Quelle gelöscht, Zieldatei erstellt, alle Import-Updates auf Disk. Erst grün → PR nach `main`. Die eigenständigen Nebenfixes dieser Session (mcpServers-Wrapper, OSGi-Version, Throwable-Catch, self-healing Nav-Errors + Index-Probe, Maven-Dep-Rewire, Launcher-Recovery) sind bereits auf `main`.