8.2.8. Prüfen und Weiterentwickeln
Die Prüfung unterscheidet gewöhnliche Entwicklungs-Builds, reproduzierbare Referenzartefakte und Tests in echten Host-Fenstern. Ein erfolgreicher Unit-Test ersetzt weder die native Toolkit-Prüfung noch die Ausführung einer Anwendungsvorschau.
Mit JDK 25 im Designer-Checkout:
./mvnw -B -ntp verify
Der vollständige Referenzablauf benötigt zusätzlich JDK 21, Python 3.10+, den qualifizierten IntelliJ-SDK und die dokumentierten lokalen NeitzelLib-Artefakte:
python3 scripts/check-bootstrap.py \
--idea-home /pfad/zur/IDE.app/Contents \
--target-java-home /absoluter/pfad/zum/jdk-21
Er prüft unter anderem Artefaktidentitäten, Java-Bytecode-Grenzen, Zielprozess-Verknüpfung, Module, Adapter, Plugin-Paketierung, Dokumentationslinks, Maven-Erfassung, Vorschauen und Lebenszyklen. Die Prüfung des tatsächlich registrierten IntelliJ-Editors ist ein zusätzlicher Ablauf aus dem IntelliJ-Kapitel.
Für diese nativen Tests wird eine macOS-Desktopsitzung benötigt. Erfolgreiche Tests des festgelegten SDK-Stands sind keine pauschale Zusage für andere IDE-Versionen oder Betriebssysteme.
Zusätzlich zu gezielten Testanwendungen kann der tatsächliche NeitzelLib-Checkout mit einer bereits qualifizierten Standalone-App geprüft werden:
python3 scripts/check-library-example.py \
--library /absoluter/pfad/zu/NeitzelLib \
--app /pfad/zu/NeitzelFXDesigner.app \
--java-home /absoluter/pfad/zum/jdk-25 \
--target-java-home /absoluter/pfad/zum/jdk-21
Das Skript arbeitet mit temporären Kopien von Anwendung und App. Ein externer Testagent steuert nur diesen Test-Host; er wird weder mit der App noch mit dem Beispiel ausgeliefert. Geprüft werden Build and Refresh, echte Component-Bilder, Person-Metadaten, Binding-Diagnosen, Quelltextbearbeitung mit Undo/Redo und Speichern, Component-Navigation und alle fünf dokumentbezogenen interaktiven Beispiele. Zum Schluss werden Worker-Ende und neue native Absturzberichte geprüft.
Diese Integration läuft für das nichtmodulare fx-example im Standalone-Host. Die vorhandenen gesonderten Testanwendungen decken Classpath, Modulpfad und IntelliJ ab. Daraus wird nicht abgeleitet, dass das Beispiel selbst bereits zu einem benannten Modul umgebaut oder in jeder Host-/Plattformkombination ausgeführt wurde.
Im dokumentierten Prüfstand bestanden 127 Tests mit dem optionalen Designer-Profil und 125 Tests im anschließenden sauberen normalen Bibliotheks-Build, jeweils ohne Fehler oder übersprungene Tests. Der normale Build enthielt danach keine PreviewProvider-Klassen oder Designer-Metadaten. Die tatsächliche Beispielintegration im gepackten Host bestand ebenfalls. Menschliche Prüfungen, die früher ausdrücklich ausgelassen wurden, bleiben weiterhin ausgelassen.
Die Designer-Prüfung vergleicht sieben installierte NeitzelLib-POM-/JAR-Dateien mit dem dokumentierten Quellstand und ihren SHA-256-Werten. Snapshot-Koordinaten allein reichen nicht, weil dieselbe Version lokal neu gebaut werden kann.
Ein neuer Build kann bereits durch Archiv-Zeitstempel andere Bytes erzeugen. Während der Entwicklung wird dafür der normale Quellstart verwendet. Soll ein neuer Stand den gespeicherten Referenzstand ersetzen, gehören zusammen:
- Sauberer Bibliotheks-Build und ausdrückliche Prüfung der Surefire-XML-Berichte trotz fest gesetztem
testFailureIgnore. - Abgleich von Quellrevision, geprüften Klassen und installierten Artefakten.
- Erneute relevante Laufzeitadapter- und Host-Prüfungen.
- Gemeinsam aktualisierte Herkunftsangaben und Prüfsummen nach erfolgreicher Prüfung.
Eine Hash-Abweichung wird nicht automatisch akzeptiert. Der Laufzeitnachweis im Repository beschreibt diesen Ablauf und die aktive Referenz. Eine Quellrevision auf main ist noch kein veröffentlichter Bibliotheks-Release.
Die vorhandene Paketierung erzeugt ein verschiebbares macOS-App-Abbild und ein ZIP mit gebündelter Java-Laufzeit und Kit. Sie ist kein grafischer Installer und enthält keine automatische Updateverwaltung. Das JDK für Build und Zielanwendung bleibt durch die Projektkonfiguration festgelegt.
Auf dem qualifizierten macOS-Rechner mit vollständigem JDK 25 und den dokumentierten Referenzartefakten wird das Paket im Designer-Checkout gebaut:
export JAVA_HOME=/absoluter/pfad/zum/jdk-25
python3 scripts/package-standalone.py --java-home "$JAVA_HOME"
Das Skript prüft die Laufzeitartefakte, baut und testet den benötigten Maven-Reaktor, ermittelt Produktionsabhängigkeiten und erzeugt mit jlink und jpackage die gebündelte Laufzeit und die native App. Standardmäßig entstehen unter target/distribution/:
NeitzelFXDesigner.app, das native Anwendungsabbild;NeitzelFXDesigner-macos.zip, das Archiv dieses Abbilds;package-manifest.json, die Herkunftsangaben und SHA-256-Inventarliste.
Vorhandene Paketausgaben werden nicht ersetzt. Für einen weiteren Build wird ein neuer Ausgabeort ausdrücklich angegeben:
python3 scripts/package-standalone.py --java-home "$JAVA_HOME" \
--destination /absoluter/pfad/zu/neuer-distribution
Die Prüfung des tatsächlichen Pakets erfolgt anschließend mit:
python3 scripts/check-standalone-package.py \
--app target/distribution/NeitzelFXDesigner.app \
--java-home "$JAVA_HOME" \
--target-java-home /absoluter/pfad/zum/jdk-21
Bei einer anderen Destination wird der --app-Pfad entsprechend angepasst. --java-home dient in dieser Prüfung zum Kompilieren des externen Testagenten; die App startet ihre eigene gebündelte Laufzeit. Der Test entpackt das ZIP an einen Ort mit Leerzeichen, prüft das Dateiinventar und startet den echten Launcher mit absichtlich ungeeignetem JAVA_HOME und eingeschränktem PATH.
Die Standardszenarien prüfen Classpath, Modulpfad, ungültige Konfiguration und fehlende Ziel-Laufzeit. Über --mode classpath, --mode modulepath, --mode invalid-configuration oder --mode missing-runtime lässt sich eine Prüfung gezielt auswählen. Kontrolliert werden unter anderem Runtime-Identität, Kit-Anpassung, native Bibliotheken, Bearbeitungsabläufe und Worker-Beendigung. Testklassen und Agent werden nicht mit dem Produkt ausgeliefert.
Die strenge Referenzprüfung gehört zu diesem Ablauf. Die numerische macOS-Bundle-Version 1.0 ist eine Vorgabe der verwendeten Paketierung und bezeichnet keinen Produkt-Release 1.0; die Anwendung bleibt 0.1.0-SNAPSHOT. Signierung, Notarisierung, öffentliche Veröffentlichung und die Qualifikation weiterer Plattformen sind zusätzliche Aufgaben. Das Bündeln des Editors macht Maven-Builds nicht offlinefähig: Anwendungs-JDK, Maven und Abhängigkeitszugriff bleiben erforderlich. Weitere Herkunftsdetails stehen in der Paketierungsdokumentation.
| Beobachtung | Prüfung und nächster Schritt |
|---|---|
| Konfiguration wird abgelehnt | Schema-Version, unbekannte Felder, expliziten Kontext, Modulpfad und vollständige lokale JDKs prüfen |
| Maven findet Designer-Snapshots nicht | Die Designer-Werkzeuge zuerst lokal bauen/installieren; ein öffentliches Snapshot-Repository ist nicht vorausgesetzt |
| Hash-Prüfung schlägt nach Bibliotheksinstallation fehl | Entwicklungsstand und qualifizierten Artefaktstand unterscheiden; nicht einfach Prüfsummen überschreiben |
| XML-Editor funktioniert, Designer in IntelliJ nicht | Genauen SDK-Build, Registry-Einstellung und Neustart prüfen; inkompatible Glass-Bibliotheken dürfen nicht vorgeladen sein |
| Component bleibt leer oder veraltet | Erfolgreichen Build, passende Beispielbeschreibung, Model-Processing-Instruction, Ressourcenzuordnung und Zielprozess-Logs prüfen |
| Java-Änderung verhindert neue Vorschau | Neu bauen oder den letzten erfolgreichen Build ausdrücklich wählen |
| Component-View hat kein Beispiel | Passenden Ressourceneintrag mit kompatiblem Provider ergänzen und neu bauen |
| Vorschau scheitert an Klasse oder Property | Zuerst die Originalanwendung prüfen; FXML, Imports und Modulzugriff korrigieren |
| Converter erscheint ungeprüft | Fähigkeitsangaben und Verhalten prüfen; Warnung und bekannten Typfehler unterscheiden |
| Metadaten sind veraltet oder doppelt | Sauberen Build nach Model-/Prozessorauswahländerung ausführen und Zuständigkeit der Quellkompilierung prüfen |
| Änderung oder Korrektur ist veraltet | Aktuellen Quelltext und neue Diagnosen laden; alte Positionen werden nicht erzwungen angewendet |
| Enum oder anderes Objekt wird falsch projiziert | Gegebenenfalls Werte im Anwendungscode initialisieren oder Source bearbeiten; Runtime-Unterstützung bedeutet nicht automatisch visuellen Property-Editor |
| Vorschau hängt oder stirbt | ready() auf blockierende Arbeit prüfen, Zeitgrenzen und Zielprozess-Logs ansehen, kleine unabhängige Beispieldienste verwenden |
Noch nicht zugesagt sind ein grafischer Einrichtungsassistent, eine produktive koordinierte Übergabe zwischen Standalone und IntelliJ, beliebige FXML-Objekteditoren, vollständige native Barrierefreiheit, weitere Betriebssystem-/SDK-Kombinationen sowie signierte öffentliche Distributionen.
Die aktuellen Kapitel beschreiben den implementierten Stand. Ältere Arbeitspaket-Dokumente im Repository behalten ihre damaligen Ergebnisse und offenen Punkte als Verlauf; sie ersetzen nicht die heutigen Funktionsbeschreibungen. Bei Erweiterungen sollten die gemeinsamen Verträge, Quelltexttransaktionen und automatisierten Host-Tests weiterverwendet werden.