Neues Modul pdf-umbenenner-packaging und zugehörige Dokumentation
- Parent-POM bindet das neue Modul ein und pflegt die jpackage-Plugin-Version - pdf-umbenenner-packaging enthält jpackage-Inputs: Launcher-Batches, Icon, Beispiel-Properties und Icon-README - CLAUDE.md und docs/betrieb.md ergänzen die MSI-/Packaging-Hinweise - Arbeitspaket-Dokumente M14 und M15 neu aufgenommen
This commit is contained in:
@@ -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
|
||||
|
||||
+71
-4
@@ -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
|
||||
|
||||
|
||||
@@ -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 (`<modules>`) 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
|
||||
<profile>
|
||||
<id>release</id>
|
||||
<build>
|
||||
<plugins>
|
||||
<!-- Shade-JAR aus Bootstrap-Modul ins Packaging-Verzeichnis kopieren -->
|
||||
<plugin>
|
||||
<groupId>org.apache.maven.plugins</groupId>
|
||||
<artifactId>maven-dependency-plugin</artifactId>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>copy-shade-jar</id>
|
||||
<phase>package</phase>
|
||||
<goals><goal>copy-dependencies</goal></goals>
|
||||
<configuration>
|
||||
<includeArtifactIds>pdf-umbenenner-bootstrap</includeArtifactIds>
|
||||
<outputDirectory>${project.build.directory}/jpackage-input</outputDirectory>
|
||||
<stripVersion>false</stripVersion>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
|
||||
<!-- jpackage -->
|
||||
<plugin>
|
||||
<groupId>org.panteleyev</groupId>
|
||||
<artifactId>jpackage-maven-plugin</artifactId>
|
||||
<version>1.6.0</version>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>create-exe</id>
|
||||
<phase>package</phase>
|
||||
<goals><goal>jpackage</goal></goals>
|
||||
<configuration>
|
||||
<type>EXE</type>
|
||||
<name>PDF-KI-Renamer</name>
|
||||
<appVersion>${project.version}</appVersion>
|
||||
<vendor>gecheckt.de</vendor>
|
||||
<input>${project.build.directory}/jpackage-input</input>
|
||||
<mainJar>pdf-umbenenner-bootstrap-${project.version}.jar</mainJar>
|
||||
<mainClass>de.gecheckt.pdf.umbenenner.bootstrap.PdfUmbenennerApplication</mainClass>
|
||||
<destination>${project.build.directory}/dist</destination>
|
||||
<icon>${project.basedir}/src/main/packaging/icon.ico</icon>
|
||||
<addModules>
|
||||
java.base,java.desktop,java.logging,java.naming,java.net.http,
|
||||
java.sql,java.xml,jdk.unsupported
|
||||
</addModules>
|
||||
<javaOptions>
|
||||
<javaOption>-Xms64m</javaOption>
|
||||
<javaOption>-Xmx512m</javaOption>
|
||||
</javaOptions>
|
||||
<winConsole>false</winConsole>
|
||||
<winShortcut>false</winShortcut>
|
||||
<winMenu>false</winMenu>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
|
||||
<!-- Batch-Dateien ins dist-Verzeichnis kopieren -->
|
||||
<plugin>
|
||||
<groupId>org.apache.maven.plugins</groupId>
|
||||
<artifactId>maven-resources-plugin</artifactId>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>copy-batch-files</id>
|
||||
<phase>package</phase>
|
||||
<goals><goal>copy-resources</goal></goals>
|
||||
<configuration>
|
||||
<outputDirectory>${project.build.directory}/dist</outputDirectory>
|
||||
<resources>
|
||||
<resource>
|
||||
<directory>src/main/packaging</directory>
|
||||
<includes>
|
||||
<include>*.bat</include>
|
||||
</includes>
|
||||
</resource>
|
||||
</resources>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
</plugins>
|
||||
</build>
|
||||
</profile>
|
||||
```
|
||||
|
||||
**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.
|
||||
@@ -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`:
|
||||
- `<type>EXE</type>` → `<type>MSI</type>`
|
||||
- Folgende Windows-spezifische jpackage-Optionen ergänzen:
|
||||
```xml
|
||||
<winShortcut>true</winShortcut>
|
||||
<winMenu>true</winMenu>
|
||||
<winMenuGroup>PDF KI Renamer</winMenuGroup>
|
||||
<winDirChooser>true</winDirChooser>
|
||||
<winShortcutPrompt>false</winShortcutPrompt>
|
||||
<installDir>PDF KI Renamer</installDir>
|
||||
```
|
||||
|
||||
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
|
||||
- `<type>MSI</type>` 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
|
||||
<appContent>
|
||||
<appContent>src/main/packaging/application.example.properties</appContent>
|
||||
</appContent>
|
||||
```
|
||||
|
||||
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`.
|
||||
`<winShortcut>true</winShortcut>` 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 `<winShortcut>true</winShortcut>` in Kombination mit
|
||||
`<winShortcutPrompt>false</winShortcutPrompt>` 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
|
||||
@@ -0,0 +1,168 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project xmlns="http://maven.apache.org/POM/4.0.0"
|
||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<parent>
|
||||
<groupId>de.gecheckt</groupId>
|
||||
<artifactId>pdf-umbenenner-parent</artifactId>
|
||||
<version>0.0.1-SNAPSHOT</version>
|
||||
</parent>
|
||||
<artifactId>pdf-umbenenner-packaging</artifactId>
|
||||
<packaging>pom</packaging>
|
||||
|
||||
<!--
|
||||
Kapselt das native Windows-Installer-Packaging (MSI).
|
||||
Im Normalbuild (ohne Profil) erzeugt dieses Modul kein Artefakt und
|
||||
fuehrt keine Plugin-Ausfuehrungen jenseits der geerbten Grundkonfiguration aus.
|
||||
Der eigentliche Installer-Build wird ueber das Profil "release" aktiviert und
|
||||
benoetigt auf der Entwicklungsmaschine zusaetzlich das WiX Toolset 3.x im PATH.
|
||||
-->
|
||||
|
||||
<properties>
|
||||
<!--
|
||||
Anwendungsversion des erzeugten Windows-Installers. Bewusst entkoppelt von
|
||||
${project.version}, damit die ausgelieferte Installer-Version unabhaengig
|
||||
vom Maven-Snapshot-Zyklus gepflegt werden kann. Wird ausschliesslich
|
||||
vom Profil "release" in der jpackage-Konfiguration ausgewertet.
|
||||
-->
|
||||
<app.version>2.5.0</app.version>
|
||||
</properties>
|
||||
|
||||
<dependencies>
|
||||
<dependency>
|
||||
<groupId>de.gecheckt</groupId>
|
||||
<artifactId>pdf-umbenenner-bootstrap</artifactId>
|
||||
<version>${project.version}</version>
|
||||
<scope>runtime</scope>
|
||||
</dependency>
|
||||
</dependencies>
|
||||
|
||||
<profiles>
|
||||
<profile>
|
||||
<id>release</id>
|
||||
<build>
|
||||
<plugins>
|
||||
<!--
|
||||
Kopiert das Shade-JAR aus dem Bootstrap-Modul in das jpackage-Eingabeverzeichnis.
|
||||
jpackage erwartet genau ein Verzeichnis, das das selbstausfuehrbare JAR enthaelt.
|
||||
-->
|
||||
<plugin>
|
||||
<groupId>org.apache.maven.plugins</groupId>
|
||||
<artifactId>maven-dependency-plugin</artifactId>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>copy-shade-jar</id>
|
||||
<phase>package</phase>
|
||||
<goals>
|
||||
<goal>copy-dependencies</goal>
|
||||
</goals>
|
||||
<configuration>
|
||||
<includeArtifactIds>pdf-umbenenner-bootstrap</includeArtifactIds>
|
||||
<outputDirectory>${project.build.directory}/jpackage-input</outputDirectory>
|
||||
<stripVersion>false</stripVersion>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
|
||||
<!--
|
||||
Erzeugt den nativen Windows-Installer (MSI) ueber jpackage.
|
||||
Die Modulliste wurde auf Basis von `jdeps` (print-module-deps) auf dem
|
||||
Shade-JAR ermittelt und um die zur Laufzeit reflektiv genutzten Module
|
||||
java.logging (Log4j2-Bridge) und java.xml (FXML/XML-Parsing) erweitert.
|
||||
WiX Toolset 3.x muss im PATH verfuegbar sein (nur auf der Entwicklungsmaschine).
|
||||
-->
|
||||
<plugin>
|
||||
<groupId>org.panteleyev</groupId>
|
||||
<artifactId>jpackage-maven-plugin</artifactId>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>create-installer</id>
|
||||
<phase>package</phase>
|
||||
<goals>
|
||||
<goal>jpackage</goal>
|
||||
</goals>
|
||||
<configuration>
|
||||
<type>MSI</type>
|
||||
<name>PDF-KI-Renamer</name>
|
||||
<appVersion>${app.version}</appVersion>
|
||||
<vendor>gecheckt.de</vendor>
|
||||
<input>${project.build.directory}/jpackage-input</input>
|
||||
<mainJar>pdf-umbenenner-bootstrap-${project.version}.jar</mainJar>
|
||||
<mainClass>de.gecheckt.pdf.umbenenner.bootstrap.PdfUmbenennerApplication</mainClass>
|
||||
<destination>${project.build.directory}/dist</destination>
|
||||
<icon>${project.basedir}/src/main/packaging/icon.ico</icon>
|
||||
<!--
|
||||
Bindet die Beispiel-Konfiguration als zusaetzliche Datei in das
|
||||
Anwendungs-Image ein. Sie landet neben den ausgelieferten JAR-Artefakten
|
||||
im Installationsverzeichnis und muss vom Betreiber nach
|
||||
C:\ProgramData\PDF KI Renamer\config\ kopiert und angepasst werden.
|
||||
-->
|
||||
<appContent>
|
||||
<appContent>src/main/packaging/application.example.properties</appContent>
|
||||
</appContent>
|
||||
<addModules>
|
||||
<module>java.base</module>
|
||||
<module>java.compiler</module>
|
||||
<module>java.desktop</module>
|
||||
<module>java.logging</module>
|
||||
<module>java.management</module>
|
||||
<module>java.naming</module>
|
||||
<module>java.net.http</module>
|
||||
<module>java.rmi</module>
|
||||
<module>java.scripting</module>
|
||||
<module>java.sql</module>
|
||||
<module>java.xml</module>
|
||||
<module>jdk.jfr</module>
|
||||
<module>jdk.unsupported</module>
|
||||
</addModules>
|
||||
<javaOptions>
|
||||
<javaOption>-Xms64m</javaOption>
|
||||
<javaOption>-Xmx512m</javaOption>
|
||||
</javaOptions>
|
||||
<winConsole>false</winConsole>
|
||||
<winShortcut>true</winShortcut>
|
||||
<winMenu>true</winMenu>
|
||||
<winMenuGroup>PDF KI Renamer</winMenuGroup>
|
||||
<winDirChooser>true</winDirChooser>
|
||||
<winShortcutPrompt>false</winShortcutPrompt>
|
||||
<installDir>PDF KI Renamer</installDir>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
|
||||
<!--
|
||||
Kopiert die beiden Start-Batch-Dateien direkt in das EXE-Ausgabeverzeichnis,
|
||||
damit sie gleichrangig neben dem erzeugten Anwendungsverzeichnis liegen.
|
||||
-->
|
||||
<plugin>
|
||||
<groupId>org.apache.maven.plugins</groupId>
|
||||
<artifactId>maven-resources-plugin</artifactId>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>copy-batch-files</id>
|
||||
<phase>package</phase>
|
||||
<goals>
|
||||
<goal>copy-resources</goal>
|
||||
</goals>
|
||||
<configuration>
|
||||
<outputDirectory>${project.build.directory}/dist</outputDirectory>
|
||||
<resources>
|
||||
<resource>
|
||||
<directory>src/main/packaging</directory>
|
||||
<includes>
|
||||
<include>*.bat</include>
|
||||
</includes>
|
||||
</resource>
|
||||
</resources>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
</plugins>
|
||||
</build>
|
||||
</profile>
|
||||
</profiles>
|
||||
</project>
|
||||
@@ -0,0 +1,2 @@
|
||||
@echo off
|
||||
"%~dp0PDF-KI-Renamer\PDF-KI-Renamer.exe" %*
|
||||
@@ -0,0 +1,2 @@
|
||||
@echo off
|
||||
"%~dp0PDF-KI-Renamer\PDF-KI-Renamer.exe" --headless %*
|
||||
@@ -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.
|
||||
@@ -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
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 127 KiB |
@@ -15,6 +15,7 @@
|
||||
<module>pdf-umbenenner-adapter-out</module>
|
||||
<module>pdf-umbenenner-bootstrap</module>
|
||||
<module>pdf-umbenenner-coverage</module>
|
||||
<module>pdf-umbenenner-packaging</module>
|
||||
</modules>
|
||||
<properties>
|
||||
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
|
||||
@@ -43,6 +44,7 @@
|
||||
<jacoco-maven-plugin.version>0.8.14</jacoco-maven-plugin.version>
|
||||
<pitest.maven.version>1.23.0</pitest.maven.version>
|
||||
<pitest.junit5.plugin.version>1.2.3</pitest.junit5.plugin.version>
|
||||
<jpackage-maven-plugin.version>1.6.0</jpackage-maven-plugin.version>
|
||||
</properties>
|
||||
|
||||
<dependencyManagement>
|
||||
@@ -193,6 +195,11 @@
|
||||
<artifactId>maven-shade-plugin</artifactId>
|
||||
<version>${maven-shade-plugin.version}</version>
|
||||
</plugin>
|
||||
<plugin>
|
||||
<groupId>org.panteleyev</groupId>
|
||||
<artifactId>jpackage-maven-plugin</artifactId>
|
||||
<version>${jpackage-maven-plugin.version}</version>
|
||||
</plugin>
|
||||
<plugin>
|
||||
<groupId>org.jacoco</groupId>
|
||||
<artifactId>jacoco-maven-plugin</artifactId>
|
||||
|
||||
Reference in New Issue
Block a user