jdt_move_type: Änderungen werden nicht auf Disk geschrieben #79

New issue

Open

opened 2026-04-10 07:11:03 +00:00 by automation · 0 comments

automation 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).