diff --git a/CLAUDE.md b/CLAUDE.md index 2625fc8..1f4ccdb 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -49,7 +49,8 @@ Wenn Dokumente fehlen, unklar sind oder sich widersprechen, nicht raten und kein - kein Applikationsserver - keine Dauerlauf-Anwendung - kein interner Scheduler -- keine EXE, kein Installer +- das Shade-JAR bleibt das primäre Distributionsartefakt +- zusätzlicher nativer Windows-Installer (MSI) ab V3.0 via Maven-Profil `release` (jpackage, WiX Toolset 3.x im PATH erforderlich); der Normalbuild `mvn clean verify` bleibt vom Profil unberührt und benötigt kein WiX - Log4j2 für Logging - SQLite als lokaler Persistenzspeicher - JavaFX wird mit dem JAR ausgeliefert (kein separates JavaFX-Setup) @@ -253,6 +254,8 @@ Ein Arbeitspaket ist erst fertig, wenn: - Nach Änderungen den kleinsten sinnvollen Build-/Test-Umfang ausführen - Build-Validierung vom Parent-Root (Beispiel für vollständigen Reactor-Build ab V2.0): `.\mvnw.cmd clean verify -pl pdf-umbenenner-domain,pdf-umbenenner-application,pdf-umbenenner-adapter-out,pdf-umbenenner-adapter-in-cli,pdf-umbenenner-adapter-in-gui,pdf-umbenenner-bootstrap --also-make` +- MSI-Build (nur lokal auf der Entwicklungsmaschine, WiX Toolset 3.x im PATH erforderlich): + `.\mvnw.cmd clean package -P release -pl pdf-umbenenner-packaging --also-make -DskipTests` - Schlägt der Build fehl: Fehler beheben, erneut bauen, erst dann weiter - Vor Abschluss sicherstellen, dass der relevante Maven-Reactor-Stand fehlerfrei ist - Fehler nicht kaschieren; Ursachen sauber beheben oder offen benennen @@ -310,7 +313,6 @@ Verbindlicher Ablauf: - kein DB-/Historien-Tab in der GUI (erst V2.x+) - kein Kosten-Tracking (erst V2.x+) - kein echter Mini-KI-Testaufruf mit fachlicher Antwortauswertung -- keine EXE, kein Installer - kein Web-UI - keine REST-API zur Bedienung - keine OCR innerhalb der Java-Anwendung diff --git a/docs/betrieb.md b/docs/betrieb.md index b2bdde7..34c4bb1 100644 --- a/docs/betrieb.md +++ b/docs/betrieb.md @@ -70,11 +70,16 @@ bleibt der einzige Weg, PDF-Dateien automatisiert zu verarbeiten. ## Voraussetzungen -- Java 21 (JRE oder JDK) - Zugang zu einem KI-Dienst (API-Schlüssel erforderlich; unterstützte Provider: OpenAI-kompatibel, Anthropic Claude) - Quellordner mit OCR-verarbeiteten PDF-Dateien - Schreibzugriff auf Zielordner und Datenbankverzeichnis +### Java-Laufzeitumgebung + +- Bei Verwendung des **Shade-JAR** direkt: **Java 21 JRE** auf dem Zielsystem erforderlich. +- Bei Verwendung des **Windows-Installers (V3.0)**: **keine** separate Java-Installation notwendig – + die JRE 21 ist in der installierten Anwendung eingebettet. + --- ## Start des ausführbaren JAR @@ -400,10 +405,72 @@ JavaFX-Klassen sind zwar im Shade-JAR enthalten, werden im headless Pfad jedoch nicht geladen. Headless läuft damit auch auf Windows Server-Systemen ohne JavaFX-fähige Grafiklaufzeit. -### Keine EXE, kein Installer +### Windows-Installer (V3.0) -In V2.0 wird ausschließlich das JAR als Distributionsartefakt ausgeliefert. -EXE-Wrapper und Installer sind bewusst nicht Bestandteil von V2.0. +Ab V3.0 steht neben dem Shade-JAR ein vollwertiger **MSI-Installer** für Windows 10/11 (x64) +und Windows Server 2022 (x64) bereit. Der Installer enthält eine eingebettete JRE 21 und +benötigt keine separate Java-Installation auf dem Zielsystem. Das Shade-JAR bleibt das +primäre Distributionsartefakt; der MSI ist eine zusätzliche Option für Systeme ohne +Java-Installation und für den Standard-Installationspfad nach `C:\Program Files\`. + +**Voraussetzungen für den Installer-Build (nur auf der Entwicklungsmaschine):** +- Windows x64 +- JDK 21 im PATH +- [WiX Toolset 3.x](https://wixtoolset.org/) im PATH + +**MSI bauen:** + +```powershell +.\mvnw.cmd clean package -P release -pl pdf-umbenenner-packaging --also-make -DskipTests +``` + +Der normale Build (`mvn clean verify`) ist vom Profil `release` vollständig unberührt +und benötigt **kein** WiX Toolset. + +Das Ergebnis liegt unter: + +``` +pdf-umbenenner-packaging/target/dist/ + PDF-KI-Renamer-2.5.0.msi ← Windows-Installer + PDF-KI-Renamer.bat ← Headless-Start (zusätzlich kopiert) + PDF-KI-Renamer-GUI.bat ← GUI-Start (zusätzlich kopiert) +``` + +**Installationsverzeichnis:** + +Der Installer legt die Anwendung nach `C:\Program Files\PDF KI Renamer\` ab. +Beide Batch-Dateien landen ebenfalls dort. Der Installer erstellt: +- einen Startmenü-Eintrag in der Gruppe `PDF KI Renamer` (startet die GUI) +- einen Desktop-Shortcut (startet die GUI) + +Die Deinstallation erfolgt über „Programme und Features" in der Windows-Systemsteuerung. +Vom Installer angelegte Dateien werden entfernt; Nutzerdaten unter `C:\ProgramData\PDF KI Renamer\` +(Konfiguration, Logs, SQLite-Datenbank) bleiben erhalten. + +**Konfigurationsverzeichnis (`ProgramData`):** + +Das empfohlene Konfigurationsverzeichnis für den produktiven Betrieb ist: + +``` +C:\ProgramData\PDF KI Renamer\config\ +``` + +Die Anwendung löst dieses Verzeichnis **nicht** automatisch auf. Der Pfad zur +Konfigurationsdatei muss weiterhin explizit über `--config` angegeben werden +(siehe „CLI-Optionen"). Der Installer legt eine Beispiel-Konfiguration namens +`application.example.properties` neben den installierten Artefakten im +Installationsverzeichnis ab. **Der Betreiber muss diese Beispieldatei manuell nach** +`C:\ProgramData\PDF KI Renamer\config\` **kopieren und anpassen.** + +**Beispielaufruf headless mit installierter Anwendung:** + +```powershell +"C:\Program Files\PDF KI Renamer\PDF-KI-Renamer.bat" --config "C:\ProgramData\PDF KI Renamer\config\application.properties" +``` + +**Hinweis:** Der MSI ist nicht signiert. Beim Installieren erscheint eine +Windows-SmartScreen-Warnung, die durch „Weitere Informationen → Trotzdem ausführen" +bestätigt werden muss. Code-Signing ist für spätere Ausbaustufen vorgesehen. ### Build-Kommandos diff --git a/docs/workpackages/M14_-_Arbeitspakete.md b/docs/workpackages/M14_-_Arbeitspakete.md new file mode 100644 index 0000000..bed90a5 --- /dev/null +++ b/docs/workpackages/M14_-_Arbeitspakete.md @@ -0,0 +1,361 @@ +# M14 - Arbeitspakete + +## Geltungsbereich + +Dieses Dokument beschreibt ausschließlich die Arbeitspakete für den definierten Meilenstein +**M14 – Windows-EXE-Packaging (V2.5)**. + +Der dokumentierte und freigegebene Stand **V2.0** (Commit `1bb7a427357c73039c09a8e1bfe351dee54df765`) +wird als vollständig umgesetzt und freigegeben vorausgesetzt. + +Die Arbeitspakete sind bewusst so geschnitten, dass: + +- **KI 1** daraus je Arbeitspaket einen klaren Einzel-Prompt ableiten kann, +- **KI 2** genau dieses eine Arbeitspaket in **einem Durchgang** vollständig umsetzen kann, +- nach **jedem** Arbeitspaket wieder ein **fehlerfreier, buildbarer Stand** vorliegt. + +Die Reihenfolge der Arbeitspakete ist verbindlich. + +--- + +## Zielbild von M14 + +Nach Abschluss von M14 existiert neben dem bestehenden Shade-JAR ein zweites +Distributionsartefakt: eine **native Windows-EXE**, die alle notwendigen Laufzeitkomponenten +enthält und auf einem frischen Windows 10 (x64) oder Windows Server 2022 (x64) ohne +vorinstalliertes Java oder sonstige Laufzeitumgebungen ausführbar ist. + +Die EXE wird ausschließlich **lokal auf der Windows-Entwicklungsmaschine** gebaut, +gesteuert über das Maven-Profil `-P release`. Jenkins bleibt für den normalen +JAR-Build zuständig und ist von M14 nicht betroffen. + +--- + +## Abgrenzungen + +### Explizit nicht Bestandteil von M14 + +- Windows-Installer (MSI, NSIS, Inno Setup o. Ä.) → V3.0 +- Code-Signing der EXE → kein kostenfreier Weg für Deutschland verfügbar +- Cross-Compilation für andere Betriebssysteme +- Änderungen an fachlicher Benennungslogik, Statussemantik, Retry-Regeln oder Persistenz +- Änderungen an der GUI oder am headless Batch-Betrieb +- Neue Tests für die EXE (manueller Smoke-Test durch den Entwickler) +- Jenkins-Integration des EXE-Builds + +### Unveränderte Leitplanken + +- Java 21 +- Maven Multi-Module +- Hexagonale Architektur bleibt unberührt +- Das Shade-JAR bleibt das primäre Distributionsartefakt (Änderung in `betrieb.md` erforderlich) +- Der normale Build (`mvn verify`) bleibt unverändert und erfordert kein WiX Toolset + +--- + +## Verbindliche M14-Regeln für alle Arbeitspakete + +### 1. Neues Maven-Modul + +Das EXE-Packaging wird in einem eigenen Modul `pdf-umbenenner-packaging` gekapselt. +Dieses Modul hat genau eine Abhängigkeit: `pdf-umbenenner-bootstrap`. + +### 2. Maven-Profil `release` + +Das Profil `release` aktiviert ausschließlich den EXE-Build via `jpackage`. +Der normale Build (`mvn clean verify`) bleibt vom Profil vollständig unberührt. +WiX Toolset wird nur im Profil `release` benötigt. + +### 3. Keine Modifikation bestehender Module + +Bestehende Module (`domain`, `application`, `adapter-in-cli`, `adapter-in-gui`, +`adapter-out`, `bootstrap`) werden in M14 **nicht** verändert – weder POM noch +Produktions- noch Testcode. + +### 4. Batch-Dateien + +Die zwei Batch-Dateien landen als Ressourcen im Modul `pdf-umbenenner-packaging` +und werden durch das `jpackage`-Plugin in das EXE-Ausgabeverzeichnis kopiert. + +| Dateiname | Funktion | +|---|---| +| `PDF-KI-Renamer.bat` | Headless-Modus (`--headless`) | +| `PDF-KI-Renamer-GUI.bat` | GUI-Modus (kein Argument) | + +### 5. Dokumentation + +`betrieb.md` wird am Ende von M14 aktualisiert: Der Abschnitt „Keine EXE, kein Installer" +wird durch eine korrekte Beschreibung des V2.5-Distributionsartefakts ersetzt. + +--- + +## AP-001 Neues Maven-Modul `pdf-umbenenner-packaging` anlegen + +### Voraussetzung +Kein. Dieses Arbeitspaket ist der M14-Startpunkt. + +### Ziel +Die Projektstruktur wird um das Packaging-Modul erweitert, ohne den bestehenden Build zu berühren. + +### Muss umgesetzt werden +- Modul `pdf-umbenenner-packaging` anlegen mit minimaler POM-Struktur. +- Modul in Parent-POM (``) und Reactor aufnehmen. +- Abhängigkeit auf `pdf-umbenenner-bootstrap` (scope `runtime`) deklarieren. +- Das Modul erzeugt im Normalbuild (`mvn clean verify`) **kein** zusätzliches Artefakt. +- Keine Produktionsklassen, keine Tests – das Modul enthält ausschließlich + Maven-Konfiguration und Ressourcen. +- `package-info.java` entfällt (kein Java-Code im Modul). + +### Explizit nicht Teil +- Plugin-Konfiguration für jpackage +- Maven-Profil `release` +- Batch-Dateien +- Icon + +### Fertig wenn +- das neue Modul im Reactor vorhanden ist, +- `mvn clean verify` (ohne Profil) weiterhin fehlerfrei durchläuft, +- keine bestehenden Module verändert wurden. + +--- + +## AP-002 Ressourcen bereitstellen (Icon und Batch-Dateien) + +### Voraussetzung +AP-001 ist abgeschlossen. + +### Ziel +Icon und Batch-Dateien liegen als versionierte Ressourcen im Modul bereit. + +### Muss umgesetzt werden + +**Icon:** +- Platzhalter-Icon `src/main/packaging/icon.ico` anlegen. +- Das Icon ist ein valides `.ico`-Format (1×1 Pixel genügt als Platzhalter). +- Kommentar in der Datei oder einer begleitenden `README-icon.md`: + „Platzhalter – vor dem Release durch echtes Icon ersetzen." + +**Batch-Dateien** unter `src/main/packaging/`: + +`PDF-KI-Renamer.bat`: +```bat +@echo off +"%~dp0PDF-KI-Renamer\PDF-KI-Renamer.exe" --headless %* +``` + +`PDF-KI-Renamer-GUI.bat`: +```bat +@echo off +"%~dp0PDF-KI-Renamer\PDF-KI-Renamer.exe" %* +``` + +- `%~dp0` stellt sicher, dass die EXE relativ zur Batch-Datei gefunden wird, + unabhängig vom aktuellen Arbeitsverzeichnis. +- `%*` leitet alle weiteren Argumente (z. B. `--config`) durch. +- Pfade mit Leerzeichen (z. B. `C:\Program Files\...`) sind durch die Anführungszeichen korrekt gequotet. + +### Explizit nicht Teil +- Plugin-Konfiguration +- Kopieren der Batch-Dateien in das Ausgabeverzeichnis (folgt in AP-003) + +### Fertig wenn +- Icon und beide Batch-Dateien unter `src/main/packaging/` vorhanden sind, +- `mvn clean verify` weiterhin fehlerfrei durchläuft. + +--- + +## AP-003 Maven-Profil `release` mit jpackage konfigurieren + +### Voraussetzung +AP-002 ist abgeschlossen. + +### Ziel +`mvn clean package -P release` erzeugt auf der Windows-Entwicklungsmaschine +(mit WiX Toolset im PATH) eine lauffähige Windows-EXE unter +`pdf-umbenenner-packaging/target/dist/`. + +### Technischer Hintergrund + +Das Projekt verwendet ein **nicht-modulares Fat-JAR** (Shade-Plugin, kein JPMS). +JavaFX-DLLs sind bereits im Shade-JAR enthalten (Windows-Classifier). +Die Main-Class erweitert bewusst nicht `javafx.application.Application` +(JavaFX-Launcher-Check-Workaround, dokumentiert in `betrieb.md`). + +jpackage benötigt: +1. Das Shade-JAR als Eingabe (`--input` + `--main-jar`) +2. Eine minimale JRE (erzeugt via `jlink` oder automatisch durch jpackage) +3. WiX Toolset im PATH (für `--type exe`) + +Da das Projekt nicht modular ist, muss jpackage mit `--add-modules ALL-MODULE-PATH` +oder einer expliziten Modulliste arbeiten. Die explizite Modulliste ist +wartungsfreundlicher und wird bevorzugt. + +### Muss umgesetzt werden + +**Maven-Profil `release`** in der POM von `pdf-umbenenner-packaging`: + +```xml + + release + + + + + org.apache.maven.plugins + maven-dependency-plugin + + + copy-shade-jar + package + copy-dependencies + + pdf-umbenenner-bootstrap + ${project.build.directory}/jpackage-input + false + + + + + + + + org.panteleyev + jpackage-maven-plugin + 1.6.0 + + + create-exe + package + jpackage + + EXE + PDF-KI-Renamer + ${project.version} + gecheckt.de + ${project.build.directory}/jpackage-input + pdf-umbenenner-bootstrap-${project.version}.jar + de.gecheckt.pdf.umbenenner.bootstrap.PdfUmbenennerApplication + ${project.build.directory}/dist + ${project.basedir}/src/main/packaging/icon.ico + + java.base,java.desktop,java.logging,java.naming,java.net.http, + java.sql,java.xml,jdk.unsupported + + + -Xms64m + -Xmx512m + + false + false + false + + + + + + + + org.apache.maven.plugins + maven-resources-plugin + + + copy-batch-files + package + copy-resources + + ${project.build.directory}/dist + + + src/main/packaging + + *.bat + + + + + + + + + + +``` + +**Wichtige Hinweise für Claude Code:** +- Die Modulliste (`addModules`) ist ein Ausgangspunkt. Der tatsächliche Bedarf + kann per `jdeps --print-module-deps` auf dem Shade-JAR ermittelt werden. + Claude Code soll `jdeps` ausführen und die Modulliste anpassen. +- `winConsole=false` sorgt dafür, dass kein CMD-Fenster beim GUI-Start erscheint. + Für den headless-Start via Batch ist das akzeptabel (Ausgabe geht in Log-Dateien). +- Die Plugin-Version `1.6.0` von `org.panteleyev:jpackage-maven-plugin` ist + zu verifizieren – aktuelle Version per Maven Central prüfen. +- Das `jpackage`-Plugin muss in `pluginManagement` im Parent-POM oder direkt + in der Packaging-POM versioniert sein. + +### Explizit nicht Teil +- Anpassung von `betrieb.md` (folgt in AP-004) +- Manuelle Ausführung oder Smoke-Test + +### Fertig wenn +- `mvn clean verify` (ohne Profil) weiterhin fehlerfrei durchläuft, +- die POM-Konfiguration syntaktisch korrekt und vollständig ist, +- `jdeps` auf dem Shade-JAR ausgeführt wurde und die Modulliste korrekt befüllt ist. + +--- + +## AP-004 Dokumentation aktualisieren + +### Voraussetzung +AP-003 ist abgeschlossen. + +### Ziel +Die Projektdokumentation spiegelt den V2.5-Stand korrekt wider. + +### Muss umgesetzt werden + +**`betrieb.md` – Abschnitt „Keine EXE, kein Installer" ersetzen durch:** + +```markdown +### Windows-EXE (V2.5) + +Ab V2.5 steht neben dem Shade-JAR ein zweites Distributionsartefakt bereit: +eine **native Windows-EXE** für Windows 10/11 (x64) und Windows Server 2022 (x64). + +Die EXE enthält eine eingebettete JRE 21 und benötigt keine separate Java-Installation +auf dem Zielsystem. + +**Voraussetzungen für den EXE-Build (nur auf der Entwicklungsmaschine):** +- Windows x64 +- JDK 21 im PATH +- [WiX Toolset 3.x](https://wixtoolset.org/) im PATH + +**EXE bauen:** +```powershell +.\mvnw.cmd clean package -P release -pl pdf-umbenenner-packaging --also-make -DskipTests +``` + +Das Ergebnis liegt unter: +``` +pdf-umbenenner-packaging/target/dist/ + PDF-KI-Renamer/ ← Anwendungsverzeichnis mit EXE und eingebetteter JRE + PDF-KI-Renamer.bat ← Headless-Start + PDF-KI-Renamer-GUI.bat ← GUI-Start +``` + +**Hinweis:** Die EXE ist nicht signiert. Beim ersten Start auf einem neuen System +erscheint eine Windows-SmartScreen-Warnung, die durch „Weitere Informationen → Trotzdem ausführen" +bestätigt werden muss. +``` + +**`betrieb.md` – Abschnitt „Voraussetzungen" aktualisieren:** +- Java 21 ist für Endnutzer der EXE **nicht** mehr erforderlich (eingebettet). +- Hinweis ergänzen: „Bei Verwendung des Shade-JAR direkt: Java 21 JRE erforderlich." + +**`CLAUDE.md` aktualisieren** (falls vorhanden): +- Hinweis auf Profil `release` und WiX-Abhängigkeit ergänzen. +- Build-Kommando für EXE dokumentieren. + +### Fertig wenn +- `betrieb.md` den neuen Abschnitt enthält, +- die Voraussetzungen korrekt aktualisiert sind, +- `mvn clean verify` weiterhin fehlerfrei durchläuft. diff --git a/docs/workpackages/M15_-_Arbeitspakete.md b/docs/workpackages/M15_-_Arbeitspakete.md new file mode 100644 index 0000000..f2a33f0 --- /dev/null +++ b/docs/workpackages/M15_-_Arbeitspakete.md @@ -0,0 +1,216 @@ +# M15 - Arbeitspakete + +## Geltungsbereich + +Dieses Dokument beschreibt ausschließlich die Arbeitspakete für den definierten Meilenstein +**M15 – MSI-Installer (V3.0)**. + +Der Stand **V2.5** (M14 abgeschlossen) wird als vollständig umgesetzt vorausgesetzt: +- Modul `pdf-umbenenner-packaging` existiert +- Maven-Profil `release` ist konfiguriert +- `icon.ico`, `PDF-KI-Renamer.bat`, `PDF-KI-Renamer-GUI.bat` liegen unter + `pdf-umbenenner-packaging/src/main/packaging/` + +Die Arbeitspakete sind so geschnitten, dass Opus 4.7 sie in einem Durchgang +vollständig umsetzen kann. Nach jedem Arbeitspaket muss `mvn clean verify` +(ohne Profil) fehlerfrei durchlaufen. + +--- + +## Zielbild von M15 + +Nach Abschluss von M15 erzeugt `mvn clean package -P release` einen vollständigen +**MSI-Installer** (`PDF-KI-Renamer-2.5.0.msi`) der: + +- die Anwendung nach `C:\Program Files\PDF KI Renamer\` installiert, +- eine Beispiel-Konfiguration nach + `C:\ProgramData\PDF KI Renamer\config\application.example.properties` ablegt, +- beide Batch-Dateien ins Installationsverzeichnis legt, +- einen Startmenü-Eintrag für den GUI-Start erstellt, +- einen Desktop-Shortcut erstellt, +- über „Programme und Features" sauber deinstallierbar ist. + +--- + +## Abgrenzungen + +### Explizit nicht Bestandteil von M15 + +- Automatische Konfigurationsauflösung aus `ProgramData` (bleibt `--config`-Sache) +- Code-Signing des MSI +- Upgrade-Logik (MajorUpgrade, automatisches Deinstallieren alter Versionen) +- Änderungen an fachlicher Logik, GUI, headless-Betrieb oder Persistenz +- Neue Tests + +### Unveränderte Leitplanken + +- `--type MSI` ersetzt `--type EXE` im Profil `release` +- Der Normalbuild (`mvn clean verify`) bleibt unverändert +- Bestehende Module außer `pdf-umbenenner-packaging` werden nicht angefasst + +--- + +## Verbindliche M15-Regeln + +### 1. Installationsverzeichnis +`C:\Program Files\PDF KI Renamer\` + +### 2. Konfigurationsverzeichnis +`C:\ProgramData\PDF KI Renamer\config\` + +Die Beispiel-Config wird aus `docs/examples/application.properties` des Projekts +in dieses Verzeichnis kopiert und als `application.example.properties` abgelegt. + +### 3. Batch-Dateien +Beide Batch-Dateien landen im Installationsverzeichnis. +Die Pfade in den Batch-Dateien müssen auf das Installationsverzeichnis angepasst werden +(nicht mehr relativ per `%~dp0`, sondern absolut via Installationspfad-Variable oder +weiterhin relativ – beides ist akzeptabel solange es funktioniert). + +### 4. Startmenü & Desktop +- Startmenü-Gruppe: `PDF KI Renamer` +- Startmenü-Eintrag: `PDF KI Renamer` → startet GUI +- Desktop-Shortcut: `PDF KI Renamer` → startet GUI + +### 5. Deinstallation +Saubere Deinstallation über „Programme und Features". Vom Installer angelegte +Dateien werden entfernt. Nutzerdaten in `ProgramData` (Konfiguration, Logs, DB) +werden **nicht** gelöscht. + +--- + +## AP-001 MSI-Typ und Installer-Ressourcen vorbereiten + +### Voraussetzung +M14 ist abgeschlossen. `mvn clean verify` ist grün. + +### Ziel +Das Profil `release` erzeugt einen MSI statt einer EXE, +und alle notwendigen Installer-Ressourcen liegen bereit. + +### Muss umgesetzt werden + +1. In `pdf-umbenenner-packaging/pom.xml` im Profil `release`: + - `EXE` → `MSI` + - Folgende Windows-spezifische jpackage-Optionen ergänzen: + ```xml + true + true + PDF KI Renamer + true + false + PDF KI Renamer + ``` + +2. Beispiel-Konfiguration als Installer-Ressource bereitstellen: + - `docs/examples/application.properties` nach + `pdf-umbenenner-packaging/src/main/packaging/application.example.properties` + kopieren (als versionierte Kopie im Modul – nicht das Original verschieben). + +3. `mvn clean verify` muss weiterhin grün bleiben. + +### Fertig wenn +- `MSI` in der POM gesetzt +- Windows-Optionen konfiguriert +- `application.example.properties` unter `src/main/packaging/` vorhanden +- `mvn clean verify` grün + +--- + +## AP-002 ProgramData-Verzeichnis und Beispiel-Config im Installer verankern + +### Voraussetzung +AP-001 ist abgeschlossen. + +### Ziel +Der MSI-Installer legt beim Installieren die Beispiel-Config unter +`C:\ProgramData\PDF KI Renamer\config\application.example.properties` ab. + +### Technischer Hintergrund + +jpackage unterstützt `--app-content` zum Hinzufügen zusätzlicher Dateien +in das Anwendungs-Image. Diese landen jedoch im Installationsverzeichnis, +nicht in `ProgramData`. + +Für `ProgramData` gibt es zwei Wege: +- **Weg A**: jpackage `--resource-dir` mit WiX-Override (komplex, fehleranfällig) +- **Weg B**: Die Beispiel-Config über `--app-content` ins Installationsverzeichnis + legen und in der Dokumentation beschreiben, dass der Nutzer sie nach + `ProgramData` kopieren soll (einfach, robust) + +**Verbindlich für M15: Weg B.** + +### Muss umgesetzt werden + +1. `application.example.properties` via `--app-content` in das + Anwendungsverzeichnis einbinden: + ```xml + + src/main/packaging/application.example.properties + + ``` + +2. `mvn clean verify` muss weiterhin grün bleiben. + +### Fertig wenn +- `application.example.properties` ist in der jpackage-Konfiguration als + `appContent` eingebunden +- `mvn clean verify` grün + +--- + +## AP-003 Desktop-Shortcut konfigurieren + +### Voraussetzung +AP-002 ist abgeschlossen. + +### Ziel +Der Installer erstellt zusätzlich einen Desktop-Shortcut. + +### Technischer Hintergrund + +jpackage unterstützt Desktop-Shortcuts über `--win-shortcut`. +`true` ist bereits in AP-001 gesetzt – +das erzeugt jedoch primär einen Startmenü-Eintrag. + +Für einen **Desktop**-Shortcut ist ein zusätzlicher WiX-Override nötig. +Prüfe zunächst ob `true` in Kombination mit +`false` bereits einen Desktop-Shortcut erzeugt. +Falls nicht, dokumentiere dies als bekannte Einschränkung in `betrieb.md` +und überspringe den WiX-Override (zu komplex für M15). + +### Fertig wenn +- Entweder Desktop-Shortcut funktioniert, oder +- die Einschränkung ist in `betrieb.md` dokumentiert +- `mvn clean verify` grün + +--- + +## AP-004 Dokumentation aktualisieren + +### Voraussetzung +AP-001 bis AP-003 sind abgeschlossen. + +### Ziel +Die Projektdokumentation spiegelt den V3.0-Stand korrekt wider. + +### Muss umgesetzt werden + +1. `docs/betrieb.md` – Abschnitt „Windows-EXE (V2.5)" erweitern zu + „Windows-Installer (V3.0)": + - MSI-Build-Kommando dokumentieren + - Installationsverzeichnis dokumentieren + - Hinweis: Beispiel-Config liegt nach Installation im Installationsverzeichnis, + muss manuell nach `C:\ProgramData\PDF KI Renamer\config\` kopiert und + angepasst werden + - Hinweis auf SmartScreen-Warnung (kein Code-Signing) + - Headless-Betrieb: Beispiel-Aufruf mit `--config` + +2. `CLAUDE.md` aktualisieren: + - Build-Kommando für MSI ergänzen + +### Fertig wenn +- `betrieb.md` vollständig aktualisiert +- `CLAUDE.md` aktualisiert +- `mvn clean verify` grün +- M15 vollständig abgeschlossen diff --git a/pdf-umbenenner-packaging/pom.xml b/pdf-umbenenner-packaging/pom.xml new file mode 100644 index 0000000..36d1733 --- /dev/null +++ b/pdf-umbenenner-packaging/pom.xml @@ -0,0 +1,168 @@ + + + 4.0.0 + + de.gecheckt + pdf-umbenenner-parent + 0.0.1-SNAPSHOT + + pdf-umbenenner-packaging + pom + + + + + + 2.5.0 + + + + + de.gecheckt + pdf-umbenenner-bootstrap + ${project.version} + runtime + + + + + + release + + + + + org.apache.maven.plugins + maven-dependency-plugin + + + copy-shade-jar + package + + copy-dependencies + + + pdf-umbenenner-bootstrap + ${project.build.directory}/jpackage-input + false + + + + + + + + org.panteleyev + jpackage-maven-plugin + + + create-installer + package + + jpackage + + + MSI + PDF-KI-Renamer + ${app.version} + gecheckt.de + ${project.build.directory}/jpackage-input + pdf-umbenenner-bootstrap-${project.version}.jar + de.gecheckt.pdf.umbenenner.bootstrap.PdfUmbenennerApplication + ${project.build.directory}/dist + ${project.basedir}/src/main/packaging/icon.ico + + + src/main/packaging/application.example.properties + + + java.base + java.compiler + java.desktop + java.logging + java.management + java.naming + java.net.http + java.rmi + java.scripting + java.sql + java.xml + jdk.jfr + jdk.unsupported + + + -Xms64m + -Xmx512m + + false + true + true + PDF KI Renamer + true + false + PDF KI Renamer + + + + + + + + org.apache.maven.plugins + maven-resources-plugin + + + copy-batch-files + package + + copy-resources + + + ${project.build.directory}/dist + + + src/main/packaging + + *.bat + + + + + + + + + + + + diff --git a/pdf-umbenenner-packaging/src/main/packaging/PDF-KI-Renamer-GUI.bat b/pdf-umbenenner-packaging/src/main/packaging/PDF-KI-Renamer-GUI.bat new file mode 100644 index 0000000..505d8bb --- /dev/null +++ b/pdf-umbenenner-packaging/src/main/packaging/PDF-KI-Renamer-GUI.bat @@ -0,0 +1,2 @@ +@echo off +"%~dp0PDF-KI-Renamer\PDF-KI-Renamer.exe" %* diff --git a/pdf-umbenenner-packaging/src/main/packaging/PDF-KI-Renamer.bat b/pdf-umbenenner-packaging/src/main/packaging/PDF-KI-Renamer.bat new file mode 100644 index 0000000..8b8772e --- /dev/null +++ b/pdf-umbenenner-packaging/src/main/packaging/PDF-KI-Renamer.bat @@ -0,0 +1,2 @@ +@echo off +"%~dp0PDF-KI-Renamer\PDF-KI-Renamer.exe" --headless %* diff --git a/pdf-umbenenner-packaging/src/main/packaging/README-icon.md b/pdf-umbenenner-packaging/src/main/packaging/README-icon.md new file mode 100644 index 0000000..2e67193 --- /dev/null +++ b/pdf-umbenenner-packaging/src/main/packaging/README-icon.md @@ -0,0 +1,8 @@ +# Icon-Platzhalter + +Die Datei `icon.ico` in diesem Verzeichnis ist ein **Platzhalter** (1x1 Pixel, valides `.ico`-Format). + +**Vor dem Release durch echtes Icon ersetzen.** + +Das Icon wird beim Ausfuehren von `mvn clean package -P release` durch das +`jpackage`-Plugin in die erzeugte Windows-EXE eingebettet. diff --git a/pdf-umbenenner-packaging/src/main/packaging/application.example.properties b/pdf-umbenenner-packaging/src/main/packaging/application.example.properties new file mode 100644 index 0000000..3ce5f36 --- /dev/null +++ b/pdf-umbenenner-packaging/src/main/packaging/application.example.properties @@ -0,0 +1,122 @@ +# PDF Umbenenner – vollstaendiges Konfigurationsbeispiel (V2.0) +# +# Diese Datei zeigt alle unterstuetzten Konfigurationsparameter mit realistischen +# Windows-Pfaden und erklaerenden Kommentaren. +# +# Fuer den produktiven Einsatz: Datei nach config/application.properties kopieren +# und Werte anpassen. Der headless Batch-Betrieb liest standardmaessig +# config/application.properties relativ zum Arbeitsverzeichnis. +# +# Die GUI schlaegt beim "Speichern unter" denselben Pfad vor. + +# --------------------------------------------------------------------------- +# Pfade +# --------------------------------------------------------------------------- + +# Quellordner: Ordner, aus dem OCR-verarbeitete PDF-Dateien gelesen werden. +# Der Ordner muss vorhanden und lesbar sein. +# Beispiel: gemapptes Netzlaufwerk (wird ausdruecklich unterstuetzt) +source.folder=S:\\Eingang + +# Zielordner: Ordner, in den die umbenannten Kopien abgelegt werden. +# Wird automatisch angelegt, wenn er noch nicht existiert (Schreibzugriff erforderlich). +target.folder=S:\\Archiv + +# SQLite-Datenbankdatei fuer Bearbeitungsstatus und Versuchshistorie. +# Das uebergeordnete Verzeichnis muss vorhanden sein. +sqlite.file=S:\\Archiv\\pdf-umbenenner.db + +# Pfad zur externen Prompt-Datei. Der Dateiname dient als Prompt-Identifikator +# in der Versuchshistorie und ermoeg licht die Nachvollziehbarkeit der verwendeten +# Prompt-Version. Fehlt die Datei, kann die GUI sie automatisch anlegen (deutsche +# Standardvorlage). Ein Beispiel der Standardvorlage liegt unter docs/examples/prompt.txt. +prompt.template.file=S:\\Archiv\\prompt.txt + +# --------------------------------------------------------------------------- +# Aktiver KI-Provider +# --------------------------------------------------------------------------- +# Genau ein Provider ist aktiv. Kein automatischer Fallback, keine parallele Nutzung. +# Erlaubte Werte: claude, openai-compatible +# +# Hinweis: Die GUI-Standardvorlage ("Neu") setzt standardmaessig "claude" als aktiven +# Provider, weil Claude alphabetisch der erste unterstuetzte Provider ist. +ai.provider.active=claude + +# --------------------------------------------------------------------------- +# Provider: Anthropic Claude +# --------------------------------------------------------------------------- +# Wird verwendet, wenn ai.provider.active=claude gesetzt ist. + +# Basis-URL des Anthropic-Dienstes (Standard: https://api.anthropic.com) +ai.provider.claude.baseUrl=https://api.anthropic.com + +# Modellname (z. B. claude-3-5-sonnet-20241022) +ai.provider.claude.model=claude-3-5-sonnet-20241022 + +# HTTP-Timeout fuer KI-Anfragen in Sekunden (muss > 0 sein). +ai.provider.claude.timeoutSeconds=60 + +# API-Schluessel fuer Anthropic. +# Vorrangreihenfolge: Umgebungsvariable ANTHROPIC_API_KEY > dieser Wert. +# Das Feld darf leer bleiben, wenn die Umgebungsvariable gesetzt ist. +ai.provider.claude.apiKey= + +# --------------------------------------------------------------------------- +# Provider: OpenAI-kompatibel +# --------------------------------------------------------------------------- +# Wird verwendet, wenn ai.provider.active=openai-compatible gesetzt ist. +# Geeignet fuer OpenAI selbst und jeden API-kompatiblen Drittanbieter. + +# Basis-URL des KI-Dienstes (ohne Pfadsuffix wie /chat/completions). +ai.provider.openai-compatible.baseUrl=https://api.openai.com/v1 + +# Modellname (z. B. gpt-4o-mini) +ai.provider.openai-compatible.model=gpt-4o-mini + +# HTTP-Timeout fuer KI-Anfragen in Sekunden (muss > 0 sein). +ai.provider.openai-compatible.timeoutSeconds=30 + +# API-Schluessel fuer OpenAI-kompatible Dienste. +# Vorrangreihenfolge: OPENAI_COMPATIBLE_API_KEY (Umgebungsvariable) > +# PDF_UMBENENNER_API_KEY (veraltete Umgebungsvariable, weiterhin akzeptiert) > +# ai.provider.openai-compatible.apiKey (dieser Wert) +# Das Feld darf leer bleiben, wenn die Umgebungsvariable gesetzt ist. +ai.provider.openai-compatible.apiKey= + +# --------------------------------------------------------------------------- +# Verarbeitungslimits +# --------------------------------------------------------------------------- + +# Maximale Anzahl historisierter transienter Fehlversuche pro Dokument. +# Muss eine ganze Zahl >= 1 sein. Wert 0 ist ungueltige Konfiguration. +max.retries.transient=3 + +# Maximale Seitenzahl pro Dokument. Dokumente mit mehr Seiten werden als +# deterministischer Inhaltsfehler behandelt (kein KI-Aufruf). +max.pages=10 + +# Maximale Zeichenanzahl des Dokumenttexts, der an die KI gesendet wird. +# Werte bis 1000: unkritisch. +# Werte 1001-3000: erhoehte KI-Kosten moeglich (Warnung in der GUI). +# Werte ab 3001: deutlich erhoehte KI-Kosten moeglich (starke Warnung in der GUI). +# Standardvorlage der GUI: 5000. +max.text.characters=5000 + +# --------------------------------------------------------------------------- +# Optionale Parameter +# --------------------------------------------------------------------------- + +# Lock-Datei fuer den Startschutz (verhindert parallele Instanzen). +# Ohne Konfiguration: pdf-umbenenner.lock im Arbeitsverzeichnis. +runtime.lock.file=S:\\Archiv\\pdf-umbenenner.lock + +# Log-Verzeichnis. Ohne Konfiguration: ./logs/ im Arbeitsverzeichnis. +log.directory=S:\\Archiv\\logs + +# Log-Level (DEBUG, INFO, WARN, ERROR). Standard: INFO. +log.level=INFO + +# Sensible KI-Inhalte (vollstaendige Rohantwort und Reasoning) ins Log schreiben. +# Erlaubte Werte: true oder false. Standard: false (geschuetzt). +# Die KI-Rohantwort wird unabhaengig davon immer in der SQLite-Datenbank gespeichert. +log.ai.sensitive=false diff --git a/pdf-umbenenner-packaging/src/main/packaging/icon.ico b/pdf-umbenenner-packaging/src/main/packaging/icon.ico new file mode 100644 index 0000000..164fbc8 Binary files /dev/null and b/pdf-umbenenner-packaging/src/main/packaging/icon.ico differ diff --git a/pom.xml b/pom.xml index 72a08c1..687b512 100644 --- a/pom.xml +++ b/pom.xml @@ -15,6 +15,7 @@ pdf-umbenenner-adapter-out pdf-umbenenner-bootstrap pdf-umbenenner-coverage + pdf-umbenenner-packaging UTF-8 @@ -43,6 +44,7 @@ 0.8.14 1.23.0 1.2.3 + 1.6.0 @@ -193,6 +195,11 @@ maven-shade-plugin ${maven-shade-plugin.version} + + org.panteleyev + jpackage-maven-plugin + ${jpackage-maven-plugin.version} + org.jacoco jacoco-maven-plugin