Files
pdf-umbenenner/pdf-umbenenner-adapter-in-gui/pom.xml
T
marcus d3fbfc4094 V2.9: Integrierte PDF-Vorschau und editierbarer Dateiname im Verarbeitungslauf
Neu im Tab "Verarbeitungslauf":
- Integrierte PDF-Vorschau der Quelldatei mit Lazy Rendering (Seite 1 sofort,
  weitere Seiten on-demand), Cache pro Selektion, "latest preview request wins"
- Editierbarer KI-Dateinamenvorschlag mit Live-Validierung, Dirty-State-Dialog
  bei Zeilen-/Tabwechsel, Schließen und Laufstart, atomare FS+DB-Transaktion
  inkl. Rollback und Fingerprint-basierter Konfliktauflösung

Architektur:
- Neuer Application-Use-Case ManualFileRenameUseCase und Outbound-Port
  TargetFileRenamePort mit Filesystem-Adapter
- Neuer GuiManualFileRenamePort, verdrahtet im Bootstrap
- GuiBatchRunResultRow um correctedFileName erweitert
- GuiBatchRunTab auf SplitPane-Layout (60/40) umgebaut, Detail-Panel mit
  KI-Begründung, FileNameEditorPane und PdfPreviewPane
- Spike-Code (PdfViewerSpike) entfernt, produktive Implementierung ersetzt

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-24 12:30:55 +02:00

225 lines
8.4 KiB
XML

<?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-adapter-in-gui</artifactId>
<packaging>jar</packaging>
<dependencies>
<!-- Internal dependencies: inbound adapter depends on application and domain -->
<dependency>
<groupId>de.gecheckt</groupId>
<artifactId>pdf-umbenenner-application</artifactId>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>de.gecheckt</groupId>
<artifactId>pdf-umbenenner-domain</artifactId>
<version>${project.version}</version>
</dependency>
<!-- JavaFX: only this module depends on JavaFX; domain/application/cli remain JavaFX-free -->
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-base</artifactId>
<classifier>win</classifier>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-graphics</artifactId>
<classifier>win</classifier>
</dependency>
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-controls</artifactId>
<classifier>win</classifier>
</dependency>
<!-- JavaFX-Swing-Interop für PDFView (AWT-Bridge, Rendering) -->
<dependency>
<groupId>org.openjfx</groupId>
<artifactId>javafx-swing</artifactId>
<version>21.0.2</version>
<classifier>win</classifier>
</dependency>
<!-- PDF-Vorschau: PDFView-Control für die integrierte Dokumentvorschau -->
<dependency>
<groupId>com.dlsc.pdfviewfx</groupId>
<artifactId>pdfviewfx</artifactId>
<version>3.1.1</version>
</dependency>
<!-- JBIG2-Codec für PDF-Bilddecodierung -->
<dependency>
<groupId>org.apache.pdfbox</groupId>
<artifactId>jbig2-imageio</artifactId>
<version>3.0.4</version>
</dependency>
<!-- JPEG2000-Codec für erweiterte PDF-Bilddecodierung -->
<dependency>
<groupId>com.github.jai-imageio</groupId>
<artifactId>jai-imageio-jpeg2000</artifactId>
<version>1.4.0</version>
</dependency>
<!-- Logging -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
</dependency>
<!-- Test dependencies -->
<!--
log4j-core on the test classpath provides the logging implementation for
tests that instantiate production classes using LogManager.getLogger.
Without it, Log4j2 falls back to SimpleLogger during test execution and
prints "Log4j2 could not find a logging implementation" at test start.
The production classpath is unaffected; log4j-core is supplied by the
bootstrap module in the shaded runtime JAR.
-->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-junit-jupiter</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.assertj</groupId>
<artifactId>assertj-core</artifactId>
<scope>test</scope>
</dependency>
<!--
Monocle: headless JavaFX platform for GUI smoke tests.
Provides the Glass platform implementation that runs JavaFX without a
physical display. Required for running GUI tests in headless CI environments
and as the designated test runtime for all GUI smoke tests.
Not part of the production classpath; test scope only.
-->
<dependency>
<groupId>org.testfx</groupId>
<artifactId>openjfx-monocle</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<!--
Surefire: configure JVM arguments for headless JavaFX via Monocle.
These properties must be set before JavaFX initializes the Glass toolkit:
glass.platform=Monocle selects the Monocle headless Glass implementation
(provided by openjfx-monocle on the test classpath);
monocle.platform=Headless selects the headless backend within Monocle;
prism.order=sw enables software rendering (no GPU required);
prism.text=t2k selects the T2K text rasterizer (headless-safe);
java.awt.headless=true signals headless mode to AWT/Swing interop layers.
Note: module-opening arguments for javafx.graphics are no longer required.
Modern JavaFX (21.x) with Monocle on Java 21 works without explicit module opening.
-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>
${argLine}
-Dglass.platform=Monocle
-Dmonocle.platform=Headless
-Dprism.order=sw
-Dprism.text=t2k
-Djava.awt.headless=true
</argLine>
</configuration>
</plugin>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<executions>
<execution>
<id>jacoco-check</id>
<phase>verify</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<!--
Coverage thresholds for the GUI adapter module.
The JavaFX Application lifecycle (Application.launch, start(Stage), stop)
is structurally untestable within the same JVM:
Application.launch() is blocking and can only be called once per JVM,
and start(Stage) requires the JavaFX runtime to supply application
parameters (getParameters()), which is only available after launch().
Monocle smoke tests cover Platform.startup() and node creation on the
FX thread. Constructor coverage is verified by structural unit tests.
Full application lifecycle coverage is provided by the executable-JAR
integration test in pdf-umbenenner-bootstrap (ExecutableJarSmokeTestIT).
The low threshold reflects this structural constraint and will remain
until Application.launch-equivalent lifecycle testing is available.
-->
<rules>
<rule>
<element>BUNDLE</element>
<limits>
<limit>
<counter>LINE</counter>
<value>COVEREDRATIO</value>
<minimum>0.10</minimum>
</limit>
<limit>
<counter>BRANCH</counter>
<value>COVEREDRATIO</value>
<minimum>0.00</minimum>
</limit>
</limits>
</rule>
</rules>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.pitest</groupId>
<artifactId>pitest-maven</artifactId>
<executions>
<execution>
<id>pitest</id>
<phase>verify</phase>
<goals>
<goal>mutationCoverage</goal>
</goals>
<configuration>
<!--
GUI adapter: PIT is skipped entirely. The JavaFX Application lifecycle
cannot be meaningfully mutation-tested without a running display or
Monocle runtime, and the remaining testable surface is too small to
produce useful mutation scores. Mutation analysis is deferred until
GUI coverage matures.
-->
<skip>true</skip>
<coverageThreshold>0</coverageThreshold>
<mutationThreshold>0</mutationThreshold>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>