main_java

VS Code Fehler vs. Maven Build SUCCESS - Erklärung

Datum: 2026-03-01
Problem: VS Code zeigt Compile-Fehler, aber mvn clean install läuft erfolgreich

Ursache: Bewusste Design-Entscheidung

Das WAR-Modul ohne JPMS

Modul: r-uu.app.jeeeraaah.backend.api.ws.rs
Typ: WAR (Jakarta EE Deployment)
Besonderheit: KEIN module-info.java (einziges Modul ohne JPMS)

Warum kein JPMS?

Aus jpms in action - jeeeraaah.md:

“Der Grund liegt in der WAR Deployment Architektur für Jakarta EE Application Server wie Open Liberty. Diese deployen WAR-Dateien standardmäßig auf dem classpath, nicht auf dem modulepath. Die Jakarta EE Server APIs sind selbst nicht JPMS-konform, sodass JPMS-Kapselungsmechanismen nicht greifen würden. Da JPMS hier keine signifikanten Vorteile bringt, wurde auf die zusätzliche Komplexität verzichtet.”

Das Problem

Maven Build (Classpath-basiert)
├─ ✅ backend.api.ws.rs → Compiled as WAR on classpath
├─ ✅ Alle dependencies verfügbar
└─ ✅ BUILD SUCCESS

VS Code Java Language Server (JPMS-erwartend)
├─ ❌ Erwartet module-info.java
├─ ❌ "ErrorResponse cannot be resolved"
├─ ❌ "import de.ruu.lib.ws.rs.ErrorResponse" nicht gefunden
└─ ❌ 1099+ falsche Fehler

Warum zeigt VS Code Fehler?

1. Maven behandelt das Modul korrekt als Classpath-Projekt
2. VS Code Java Language Server analysiert alle Module und erwartet JPMS überall
3. Ohne module-info.java kann VS Code die Module-Abhängigkeiten nicht auflösen
4. Imports aus anderen Modulen (z.B. de.ruu.lib.ws.rs.ErrorResponse) werden als “nicht gefunden” markiert

Lösungsoptionen

Option 1: VS Code-Konfiguration anpassen ⚙️ (EMPFOHLEN)

Status: ✅ Bereits implementiert in .vscode/settings.json

{
  "java.errors.incompleteClasspath.severity": "ignore",
  "java.jdt.ls.vmargs": "-Xmx4G"
}

Effekt: Unterdrückt Classpath-Warnungen, aber Fehler bleiben sichtbar

Option 2: Projekt-Clean durchführen 🧹

cd /home/r-uu/develop/github/main/root
mvn clean

Dann in VS Code:

1. Ctrl+Shift+P → “Java: Clean Java Language Server Workspace”
2. Ctrl+Shift+P → “Developer: Reload Window”

Effekt: Cache wird geleert, aber Problem bleibt strukturell

Option 3: backend.api.ws.rs zu JPMS migrieren 🔧 (AUFWÄNDIG)

Vorteil:

• VS Code würde alle Abhängigkeiten korrekt auflösen
• Konsistenz mit allen anderen Modulen

Nachteil:

• Widerspricht der ursprünglichen Design-Entscheidung
• Jakarta EE Server APIs sind nicht JPMS-konform
• Deployment-Komplexität steigt
• Kein funktionaler Vorteil

Aufwand: ~2-4 Stunden + Testing

Option 4: WAR-Modul aus Workspace ausschließen 📂

Erstelle .vscode/settings.json:

{
  "java.project.excludedFolders": [
    "**/backend/api/ws_rs"
  ]
}

Effekt: Module wird nicht analysiert → keine Fehler, aber auch kein IntelliSense

Option 5: VS Code-Fehler ignorieren ✋ (PRAGMATISCH)

Realität:

• ✅ Maven Build funktioniert
• ✅ Tests laufen
• ✅ Deployment funktioniert
• ❌ VS Code zeigt falsche Fehler

Empfehlung: Fehler ignorieren und mit Maven arbeiten

# Entwicklungs-Workflow
mvn compile              # Schneller Check
mvn clean install        # Vollständiger Build
mvn test                 # Tests ausführen

Empfehlung

Kurzfristig (heute):

• ✅ .vscode/settings.json angepasst (bereits erledigt)
• ✅ Verstehen, dass VS Code-Fehler falsch-positiv sind
• ✅ Maven als “Source of Truth” verwenden

Mittelfristig (optional):

• Evaluieren, ob JPMS-Migration des WAR-Moduls sinnvoll ist
• Alternative IDEs testen (IntelliJ IDEA hat bessere Classpath/Module-Path-Unterstützung)

Langfristig:

• Jakarta EE wird zunehmend JPMS-kompatibel
• Open Liberty könnte bessere JPMS-Unterstützung bekommen
• Dann wäre Migration einfacher

Status Quo

✅ Was funktioniert:

• Maven Build (alle 88 Module)
• Tests
• Deployment auf Open Liberty
• Laufzeit-Verhalten

❌ Was nicht funktioniert:

• VS Code IntelliSense für backend.api.ws.rs
• VS Code Problem-Ansicht (zeigt 1099 falsche Fehler)

Fazit

Dies ist kein echter Fehler, sondern ein Tool-Kompatibilitätsproblem:

• Design-Entscheidung: WAR-Modul ohne JPMS ✅ korrekt
• Maven Build: ✅ funktioniert
• VS Code: ❌ versteht Hybrid-Setup (JPMS + Classpath) nicht vollständig

Empfohlene Lösung: Mit Maven arbeiten, VS Code-Fehler ignorieren.

This site is open source. Improve this page.