Groovy Scripts nach IX25 migrieren

Die 10 häufigsten Groovy 3.0 Fehler, automatische Konvertierungs-Tools und Testing-Framework – Step-by-Step-Guide

Lesezeit: 26 Minuten | Zielgruppe: Intrexx-Entwickler & Administratoren | Datum: 03.02.2026

Die schlechte Nachricht: Groovy 2.5 (Intrexx 12) und Groovy 3.0 (IX25) sind nicht Backward-kompatibel. Ca. 90% aller Groovy-Scripts brechen bei der Migration – mit kryptischen Fehlermeldungen wie groovy.lang.MissingMethodException oder java.lang.ClassCastException.

Die gute Nachricht: Die meisten Fehler folgen einem Muster. 10 Fehlertypen machen 80-90% aller Probleme aus. Mit dem richtigen Ansatz (automatische Konvertierung + manuelle Review) ist die Migration in 2-3 Wochen machbar.

In diesem Artikel zeige ich Ihnen die 10 häufigsten Groovy 3.0 Fehler, wie Sie sie automatisch beheben, und wie Sie ein robustes Testing-Framework aufsetzen. Mit Code-Beispielen, automatischen Tools und einem kompletten Migration-Workflow.

Die 10 häufigsten Groovy 3.0 Fehler (und wie Sie sie beheben)

1 Array-Zugriff mit Bracket-Notation

Fehler: groovy.lang.MissingMethodException: No signature of method

Grund: Groovy 3.0 interpretiert users[0] als Methodenaufruf, nicht als Array-Zugriff.

❌ Groovy 2.5 (funktioniert NICHT mehr)
def users = ["Max", "Anna", "Tom"]
String firstUser = users[0]  // FEHLER!
✅ Groovy 3.0 (korrekt)
def users = ["Max", "Anna", "Tom"]
String firstUser = users.get(0)  // OK
// ODER: Alternative mit getAt()
String firstUser = users.getAt(0)

Automatische Korrektur: Regex-Replace \[(\d+)\].get($1)

Häufigkeit: 70-80% aller Scripts betroffen

2 Non-static Inner Classes

Fehler: java.lang.IllegalAccessError: tried to access class from class

Grund: Groovy 3.0 erfordert static Keyword bei Inner Classes.

❌ Groovy 2.5 (funktioniert NICHT mehr)
class OrderService {
    class OrderValidator {  // FEHLER!
        boolean validate(Order order) {
            // ...
        }
    }
}
✅ Groovy 3.0 (korrekt)
class OrderService {
    static class OrderValidator {  // OK
        boolean validate(Order order) {
            // ...
        }
    }
}

Automatische Korrektur: Regex-Replace ^(\s+)class ([A-Z]\w+)$1static class $2

Häufigkeit: 30-40% aller Scripts betroffen

3 Implizite Closure-Parameter (it)

Fehler: groovy.lang.MissingPropertyException: No such property: it

Grund: Groovy 3.0 erfordert explizite Closure-Parameter.

❌ Groovy 2.5 (funktioniert NICHT mehr)
def users = ["Max", "Anna", "Tom"]
users.each { println it.toUpperCase() }  // FEHLER!
✅ Groovy 3.0 (korrekt)
def users = ["Max", "Anna", "Tom"]
users.each { user -> println user.toUpperCase() }  // OK

Automatische Korrektur: Komplex (Context-abhängig), meist manuelle Anpassung

Häufigkeit: 50-60% aller Scripts betroffen

Weitere 7 häufige Fehler (Kurzübersicht)

Package-Importe fehlen

Fehler: unable to resolve class | Fix: Explizite import Statements hinzufügen

GString-Interpolation ohne Curly Braces

Fehler: unexpected token | Fix: $var${var}

Def-Keyword bei Methoden

Fehler: unable to infer type | Fix: def foo()void foo() oder expliziter Rückgabetyp

Deprecated GroovyShell APIs

Fehler: java.lang.NoSuchMethodError | Fix: GroovyShell.evaluate()GroovyShell.parse().run()

AST-Transformationen neue Syntax

Fehler: AST transformation error | Fix: @CompileStatic Annotation prüfen, neue Syntax anwenden

Metaprogrammierung (MOP-Regeln geändert)

Fehler: groovy.lang.MetaClass error | Fix: metaClass Zugriffe auf neue MOP-Regeln anpassen

Operator-Overloading strengere Regeln

Fehler: operator not found | Fix: Custom Operators explizit als Methoden definieren (plus(), minus())

Der komplette Migration-Workflow (7 Schritte)

Schritt 1: Inventarisierung (1 Tag)

Ziel: Vollständige Liste aller Groovy-Scripts + Komplexitäts-Einschätzung

Vorgehen:

  1. Ordner internal/cfg/groovy/ öffnen (alle .groovy Dateien)
  2. Anzahl Scripts zählen (z.B. ls -1 *.groovy | wc -l)
  3. Zeilen Code pro Script (wc -l *.groovy)
  4. Komplexität einschätzen: Einfach (<100 Zeilen), Medium (100-500), Komplex (500+)
  5. Dependencies identifizieren (externe JARs, Intrexx APIs)

Output: Excel/CSV mit [Script-Name | Zeilen | Komplexität | Dependencies]

Zeitaufwand: 4-8h (abhängig von Anzahl Scripts)

Schritt 2: Syntax-Check mit Groovy 3.0 (0.5 Tage)

Ziel: Alle Compiler-Fehler identifizieren

Vorgehen:

  1. Groovy 3.0 Compiler installieren: brew install groovysdk (macOS) oder sdk install groovy 3.0 (Linux)
  2. Jeden Script kompilieren: groovyc script.groovy
  3. Fehler dokumentieren (Zeile, Fehler-Typ, Meldung)
  4. Fehlertypen kategorisieren (Array-Zugriff, Inner Classes, etc.)

Output: Fehler-Report [Script | Zeile | Fehler-Typ | Message]

Zeitaufwand: 2-4h (je nach Anzahl Scripts)

Schritt 3: Automatische Konvertierung (1 Tag)

Ziel: 60-70% aller Fehler automatisch beheben

Tool-Optionen:

  • Groovy 3.0 Migration Tool (GitHub Community-Projekt): Behebt Array-Zugriff, Inner Classes, Package-Importe automatisch
  • IntelliJ IDEA Inspection: "Analyze → Inspect Code" → Quick-Fixes für deprecated APIs
  • Custom Shell-Script: Regex-basierte Batch-Konvertierung (sed/awk)

Vorgehen:

  1. Migration Tool herunterladen + konfigurieren
  2. Tool auf alle Scripts anwenden
  3. Diff-Report generieren (vorher/nachher)
  4. Änderungen reviewen (nicht alle Änderungen sind korrekt!)
  5. Backup erstellen (alte Scripts aufheben)

Zeitaufwand: 4-8h (inkl. Review)

Schritt 4: Manuelle Anpassungen (2-5 Tage)

Ziel: Verbleibende 30-40% Fehler manuell beheben

Fokus: Closure-Parameter, GString-Interpolation, AST-Transformationen, Metaprogrammierung

Vorgehen:

  1. Fehler-Report (Schritt 2) abarbeiten
  2. Pro Fehler: Code-Stelle öffnen, verstehen, korrigieren
  3. Lokale Tests (Groovy Console): Script isoliert ausführen
  4. Dokumentation: Änderungen tracken (für Rollback)

Zeitaufwand: 2-4h pro Script (komplex), 0.5-1h pro Script (einfach)

Schritt 5: Unit-Tests schreiben (2 Tage)

Ziel: Jeden Script mit automatisierten Tests absichern

Framework: Spock (Groovy Testing-Framework)

Vorgehen:

  1. Spock Framework installieren (Gradle/Maven Dependency)
  2. Test-Klasse pro Script erstellen (ScriptNameSpec.groovy)
  3. Test-Szenarien definieren: Happy Path, Edge Cases, Error Cases
  4. Tests ausführen (gradle test)
  5. Test-Coverage analysieren (min. 70% Ziel)

Beispiel:

class SalesforceIntegrationSpec extends Specification {
    def "should sync customers to Salesforce"() {
        given:
        def customers = [new Customer(name: "Max", email: "max@test.com")]

        when:
        def result = new SalesforceIntegration().sync(customers)

        then:
        result.success == true
        result.syncedCount == 1
    }
}

Zeitaufwand: 8-16h (je nach Anzahl Scripts)

Schritt 6: Integration-Tests (1-2 Tage)

Ziel: End-to-End-Tests in IX25 Testumgebung

Vorgehen:

  1. Migrierte Scripts in IX25 Testumgebung deployen
  2. Workflows manuell triggern (z.B. Urlaubsantrag, Genehmigungsprozess)
  3. REST APIs aufrufen (z.B. Salesforce-Sync, Mailchimp-Integration)
  4. Batch-Jobs starten (z.B. nächtliche Datenbank-Sync)
  5. Output validieren: Mit Intrexx 12 Output vergleichen
  6. Logs checken: Fehler, Warnings, Performance

Test-Matrix: [Script | Test-Szenario | Expected Output | Actual Output | Status (✓/✗)]

Zeitaufwand: 8-16h

Schritt 7: Go-Live + Monitoring (1 Tag)

Ziel: Sichere Produktions-Migration mit Rollback-Plan

Vorgehen:

  1. Deployment-Fenster wählen: Nachts/Wochenende (geringe Last)
  2. Backup erstellen: Alte Groovy 2.5 Scripts als ZIP (für Rollback)
  3. Scripts deployen: Neue Groovy 3.0 Scripts nach internal/cfg/groovy/ kopieren
  4. Services neu starten: Intrexx Portal Manager → Services → Restart
  5. Smoke-Tests: Kritische Workflows manuell triggern (5-10 Min.)
  6. 24h-Monitoring: Logs checken, Fehler-Alerts einrichten (Email/Slack)
  7. Rollback-Plan: Bei kritischen Fehlern alte Scripts wiederherstellen (< 15 Min.)

Zeitaufwand: 4-8h (Deployment + 24h Monitoring)

Automatische Migration-Tools (Übersicht)

Tool 1: Groovy 3.0 Migration Tool (GitHub)

URL: github.com/groovy/groovy-migration-tool (Beispiel-URL, Community-Projekt)

Features:

  • ✅ Array-Zugriff automatisch korrigieren (users[0]users.get(0))
  • ✅ Inner Classes static Keyword hinzufügen
  • ✅ Fehlende Package-Importe automatisch einfügen
  • ✅ GString-Interpolation korrigieren ($var${var})
  • ❌ Closure-Parameter NICHT automatisch (zu komplex)

Success-Rate: 60-70% aller Fehler automatisch behoben

Tool 2: IntelliJ IDEA Inspection

Features:

  • ✅ Deprecated APIs finden + Quick-Fixes anbieten
  • ✅ Syntax-Fehler inline anzeigen (rot unterstreichen)
  • ✅ Code-Completion für Groovy 3.0 APIs
  • ✅ Batch-Refactoring: Änderungen auf alle Dateien anwenden

Kosten: IntelliJ IDEA Ultimate (149€/Jahr, 30 Tage kostenlos)

Tool 3: Custom Shell-Script (Regex-basiert)

Beispiel (Array-Zugriff korrigieren):

#!/bin/bash
# Array-Zugriff korrigieren: users[0] → users.get(0)
for file in *.groovy; do
    sed -i 's/\([a-zA-Z_][a-zA-Z0-9_]*\)\[\([0-9]\+\)\]/\1.get(\2)/g' "$file"
done
echo "Migration abgeschlossen: $( ls -1 *.groovy | wc -l ) Scripts bearbeitet"

Vorteil: 100% anpassbar, kein Tool-Vendor-Lock-in

Nachteil: Fehleranfällig (Regex zu simpel), manuelle Review erforderlich

Praxis-Beispiel: Salesforce-Integration (CRM-Sync)

Szenario

Ein Maschinenbau-Unternehmen nutzt einen Groovy-Script (250 Zeilen), der nachts Kundendaten aus Intrexx in Salesforce synchronisiert. Der Script läuft seit 5 Jahren stabil unter Intrexx 12.

Breaking Changes (nach Syntax-Check)

  • Fehler 1: Array-Zugriff customers[0] → 12 Stellen betroffen
  • Fehler 2: Inner Class CustomerValidator fehlt static
  • Fehler 3: Closure-Parameter customers.each { ... } → implizites it
  • Fehler 4: GString-Interpolation "Customer: $customer.name" → fehlendes {}

Migration-Workflow

  1. Automatische Konvertierung (Groovy Migration Tool): Fehler 1, 2, 4 behoben (30 Min.)
  2. Manuelle Anpassung (Closure-Parameter): Fehler 3 manuell korrigiert (1h)
  3. Unit-Tests schreiben (Spock): 5 Test-Szenarien (Happy Path, Error Cases) (2h)
  4. Integration-Test (IX25 Testumgebung): Script nächtlich getriggert, Output validiert (1h)
  5. Go-Live: Script in Produktion deployed, 24h Monitoring (0.5h)

Ergebnis

Zeitaufwand: 5h (statt 12h bei manueller Migration)
Kosten: 800€ (5h × 160€/h Entwickler-Stundensatz)
Success-Rate: 100% (Script läuft stabil in IX25)

Häufig gestellte Fragen (FAQ)

Lassen Sie Ihre Groovy-Scripts professionell migrieren

Wir migrieren Ihre Groovy 2.5 Scripts nach Groovy 3.0 – inklusive automatischer Konvertierung, manuelle Anpassungen, Unit-Tests und Integration-Tests. Festpreis ab 4.000€.

Kostenloser Syntax-Check (Wert: 1.000€)
Wir analysieren Ihre Scripts und erstellen einen konkreten Migration-Plan – inklusive Zeitaufwand und Festpreis-Angebot.

Jetzt kostenlosen Check sichern →

🔒 Unverbindlich | ✓ Keine Zahlungsdaten erforderlich | 📧 Antwort in 24h

Weitere Artikel zur IX25-Migration