Refactoring schlägt fehl wenn betroffene Projekte Compile-Errors haben #75

New issue

Open

opened 2026-03-09 09:22:27 +00:00 by automation · 0 comments

automation commented

2026-03-09 09:22:27 +00:00

Collaborator

Problem

Wenn ein Refactoring gestartet wird (z.B. jdt_rename_element mit PACKAGE), aber eines der betroffenen Projekte Compile-Errors hat, wird der Request mit einer Fehlermeldung abgelehnt.

checkFinalConditions() meldet Compile-Errors in betroffenen Projekten als Refactoring-Fehler, obwohl das Refactoring selbst technisch durchführbar wäre.

Erwartetes Verhalten

Compile-Errors in betroffenen Projekten sollten als Warning gemeldet werden, nicht als blockierender Fehler
Alternativ: Option force=true oder ignoreCompileErrors=true um das Refactoring trotzdem durchzuführen
Eclipse IDE zeigt in diesem Fall einen Dialog mit "Proceed anyway?" — im Headless-Modus fehlt dieses Verhalten

Kontext

Entdeckt beim Testen von #73 (Package-Rename). In einem Workspace mit ~29 Projekten ist es realistisch, dass nicht alle fehlerfrei kompilieren.

## Problem Wenn ein Refactoring gestartet wird (z.B. `jdt_rename_element` mit `PACKAGE`), aber eines der betroffenen Projekte Compile-Errors hat, wird der Request mit einer Fehlermeldung abgelehnt. `checkFinalConditions()` meldet Compile-Errors in betroffenen Projekten als Refactoring-Fehler, obwohl das Refactoring selbst technisch durchführbar wäre. ## Erwartetes Verhalten - Compile-Errors in betroffenen Projekten sollten als **Warning** gemeldet werden, nicht als blockierender Fehler - Alternativ: Option `force=true` oder `ignoreCompileErrors=true` um das Refactoring trotzdem durchzuführen - Eclipse IDE zeigt in diesem Fall einen Dialog mit "Proceed anyway?" — im Headless-Modus fehlt dieses Verhalten ## Kontext Entdeckt beim Testen von #73 (Package-Rename). In einem Workspace mit ~29 Projekten ist es realistisch, dass nicht alle fehlerfrei kompilieren.