konrad/JavaFXMavenApp
Template
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/main'

Browse Source
This commit is contained in:
Konrad Neitzel 2024-05-13 13:54:36 +02:00
commit 6583ec4514
16 changed files with 1199 additions and 57 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
README.md
View File

@ -2,50 +2,25 @@
Example Maven Project for a JavaFX Application.
**The application is no longer a modular application so there are no problems with dependencies that are not providing a
module-info.**
**Update**: Added reporting to create a site (html documentation of project)
**Update**: Java 21 is now fully supported
This projects includes multiple plugins:
- Build of an App-Image using JPackage
- Use of Maven Wrapper
- Static code analysis with PMD and Spotbugs
- Check of dependency updates during build
- Build of an App-Image using JPackage
- JavaFX plugin to start application
**Important** All commands following should be issued in the root directoy of the project (the directory where you find the pom.xml)
**Requirements**
To use this Template, all you need is a local Java Installation.
My current advice is to use a long term supported (LTS) version of either Java 17 or Java 21.
*Quick Start*
**[Documentation in English](documentation/en/_Index.md)**
- Simply download a zip file of this project and unzip it somewhere on your computer
- open the pom.xml and change the settings at the start of the document to fit with your project
**[Dokumentation in Deutsch](documentation/de/_Index.md)**
*How to use this project*
**build the application**
To build the application, maven / the maven wrapper can be used. Simply do a
```./mvnw package```
to build the application.
(simply call mvnw instead of ./mvnw on windows!)
**Clean up**
To clean up the project, call
```./mvnw package```
**Start the application from commandline**
```./mvnw javafx:run```
**Build the Image**
To build the image, the profile Image must be used:
```./mvnw -DImage install```
**Important** You cannot build an image using the javafx plugin. The javafx plugin would require that you build a modular
Java application and all dependencies providing a module description.
**Static code analysis**
The static code analysis is done when you build the application. The results can be found in
- ./target/pmx.xml
- ./target/spotbugsXml.xml
**Important: ChatGPT was utilized to generate the documentation based on
predefined content specifications, as it represents the fastest way to produce
comprehensive documentation.**

210
documentation/de/ImageCreation.md Normal file
View File

@ -0,0 +1,210 @@
# Erstellung von Images
Wenn die Anwendung weiter gegeben werden soll, dann benötigt man das fertig übersetzte Programm sowie
ggf. noch eine Anleitung zur Installation.
Die Erstellung des Images benötigt zwei Schritte:
1. Die Bereitstellung aller notwendigen Dateien. Die umfasst neben den übersetzen Klassen und den Ressourcen der
Anwendung auch noch alle Abhängigkeiten.
2. Erstellung eines sogenannten Images: Einer Verzeichnisstruktur mit Dateien zusammen mit einem Binary, das gestartet
werden kann.
## Aufruf
Um das Image zu bauen, ist Maven mit dem Profil Image und dem Ziel install zu starten.
Da es teilweise zu Problemen kommt, wenn Dateien überschrieben werden müssen, sollte
als Erstes ein clean durchlaufen.
Dies kann in einem Durchlauf erfolgen:
```shell
mvnw -PImage clean install
```
## Beschreibung des Image Profils
### Das Profil
```xml
<profile>
<id>Image</id>
<activation>
<property>
<name>Image</name>
</property>
</activation>
<build>
<plugins>
<!-- ... -->
</plugins>
</build>
</profile>
```
- Das Profil hat eine Id: Image. Damit ist es möglich, das Profil über -PImage auszuwählen.
- Durch die activation Property ist es zusätzlich möglich, das Profil auch über ein Define auszuwählen: -DImage
- In dem Profil selbst sind dann Plugins untergebracht.
### maven-dependency-plugin
```xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>${maven.dependency.plugin}</version>
<executions>
<!-- erstmal Abhängigkeiten für den Class-Path kopieren -->
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/modules</outputDirectory>
<includeScope>runtime</includeScope>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>false</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
</execution>
<!-- dazu noch das Projekt-JAR -->
<execution>
<id>copy</id>
<phase>install</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/modules</outputDirectory>
<artifactItems>
<artifactItem>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<type>${project.packaging}</type>
<destFileName>${project.build.finalName}.jar</destFileName>
</artifactItem>
</artifactItems>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
</execution>
</executions>
</plugin>
```
Das Maven Dependency Plugin dient dem Kopieren der benötigten Dateien. Dies erfolgt in zwei Schritten:
1. Es werden alle Abhängigkeiten kopiert
2. Es wird das erzeugte Artefact (das jar File mit dem Code des Projekts) kopiert
#### copy-dependencies
Die Ausführung copy-dependencies innerhalb des maven-dependency-plugins ist darauf ausgelegt, den Prozess des Kopierens
aller notwendigen Laufzeitabhängigkeiten in ein festgelegtes Ausgabeverzeichnis zu automatisieren. Diese Ausführung ist
entscheidend dafür, dass alle für die Anwendung erforderlichen Laufzeitkomponenten im Bereitstellungsumfeld verfügbar
sind. Die Konfiguration stellt sicher, dass Abhängigkeiten effizient während der Package-Phase des Build-Prozesses
behandelt werden.
Wesentliche Aspekte der Ausführung von copy-dependencies umfassen:
- **phase**: Sie ist so konfiguriert, dass sie während der package-Phase ausgeführt wird, was der ideale Zeitpunkt ist,
um alle für die verpackte Anwendung benötigten Abhängigkeiten zu sammeln.
- **goal**: Das Ziel copy-dependencies wird genutzt, um das Kopieren der Abhängigkeiten durchzuführen.
- **Konfiguration**: Wichtige Konfigurationseinstellungen beinhalten:
- - **outputDirectory**: Gibt das Verzeichnis an, in das alle Abhängigkeiten kopiert werden, typischerweise ein
Unterverzeichnis im Build-Verzeichnis wie /modules.
- - **includeScope**: Auf runtime gesetzt, um sicherzustellen, dass nur bei der Laufzeit benötigte Abhängigkeiten
einbezogen werden, was dazu beiträgt, die Größe und Komplexität der Bereitstellung zu reduzieren.
- - **overWriteReleases, overWriteSnapshots und overWriteIfNewer**: Diese Einstellungen regeln, wie existierende Dateien
im Zielverzeichnis behandelt werden. Sie verhindern das Überschreiben von stabilen Release-Versionen und
Snapshot-Versionen, es sei denn, eine neuere Version wird kopiert, was dazu beiträgt, die Integrität und Aktualität der
Abhängigkeitsdateien zu erhalten.
Diese Konfiguration stellt sicher, dass alle notwendigen Abhängigkeiten vorbereitet und am richtigen Ort verfügbar sind, bevor die Anwendung verpackt wird, was einen reibungslosen Übergang zu den Montage- und Bereitstellungsphasen erleichtert.
#### copy project artefact
Die Ausführung copy project artifact im maven-dependency-plugin ist darauf ausgerichtet, das Kopieren des endgültigen
Projektartefakts, typischerweise der ausführbaren JAR-Datei, in ein festgelegtes Ausgabeverzeichnis zu erleichtern.
Dieser Schritt ist entscheidend, da er sicherstellt, dass die aktuellste und überprüfte Version der Anwendung für die
Verpackung und Bereitstellung verfügbar ist.
Wesentliche Aspekte der Ausführung von copy project artifact umfassen:
- **Phase**: Konfiguriert für die Ausführung während der install-Phase, die auf die Build- und Verifizierungsprozesse
folgt. Dieser Zeitpunkt ist entscheidend, um sicherzustellen, dass nur vollständig gebaute und getestete Artefakte in
die Bereitstellungspipeline übernommen werden.
- **Ziele**: Nutzt das Ziel copy, um den Kopiervorgang durchzuführen.
- **Konfiguration**: Wichtige Konfigurationseinstellungen beinhalten:
- - **outputDirectory**: Gibt das Zielverzeichnis an, in dem die JAR-Datei des Projekts platziert wird, typischerweise
innerhalb des Build-Verzeichnisses unter /modules.
- - **artifactItems**: Eine Liste, die die spezifischen zu kopierenden Projektartefakte detailliert beschreibt. Dies umfasst:
- - - **groupId, artifactId, version und type**: Diese Attribute identifizieren das Projektartefakt eindeutig im
Maven-Repository und stellen sicher, dass die korrekte Datei ausgewählt wird.
- - - **destFileName**: Gibt den Namen der Datei an, wie sie im Ausgabeverzeichnis erscheinen soll. Dies ermöglicht
eine Anpassung des Ausgabedateinamens, was besonders nützlich ist, um die Versionskontrolle zu wahren oder zwischen
verschiedenen Builds zu unterscheiden.
- - **overWriteIfNewer**: Stellt sicher, dass eine vorhandene Datei nur überschrieben wird, wenn die neue Datei aktueller ist, was bei der Verwaltung mehrerer Versionen hilft und sicherstellt, dass bei der Bereitstellung immer das aktuellste Artefakt verwendet wird.
Diese Einrichtung stellt sicher, dass das Projektartefakt korrekt an den geeigneten Ort kopiert wird, wodurch die
Integrität und Bereitschaft der Anwendung für die Bereitstellung gewahrt bleibt. Sie bietet einen robusten Mechanismus
zur Verwaltung der Artefakte in einer Build-Pipeline, der sich an den Best Practices für kontinuierliche Integration
und Auslieferung orientiert.
### jpackage-maven-plugin
```xml
<plugin>
<groupId>com.github.akman</groupId>
<artifactId>jpackage-maven-plugin</artifactId>
<version>${jpackage.maven.plugin}</version>
<configuration>
<name>${appName}</name>
<type>IMAGE</type>
<modulepath>
<dependencysets>
<dependencyset>
<includenames>
<includename>javafx\..*</includename>
</includenames>
</dependencyset>
</dependencysets>
</modulepath>
<addmodules>
<addmodule>javafx.controls</addmodule>
<addmodule>javafx.graphics</addmodule>
<addmodule>javafx.fxml</addmodule>
<addmodule>javafx.web</addmodule>
</addmodules>
<mainclass>${main.class}</mainclass>
<input>${project.build.directory}/modules</input>
<mainjar>${jar.filename}.jar</mainjar>
</configuration>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>jpackage</goal>
</goals>
</execution>
</executions>
</plugin>
```
Das jpackage-maven-plugin erleichtert die Erstellung eines eigenständigen Anwendungsimages mithilfe des JPackage-Tools
von Java, das Teil des JDK ist. Dieses Plugin ist so konfiguriert, dass es während der 'install'-Phase des
Maven-Build-Lebenszyklus ausgeführt wird. Es bündelt die Anwendung zusammen mit ihren Abhängigkeiten und der
Java-Laufzeitumgebung in ein plattformspezifisches Paket, was die Distribution und Bereitstellung erleichtert.
Wichtige Konfigurationen für dieses Plugin umfassen:
- **name** und **type**: Gibt den Namen der Anwendung an und setzt den Pakettyp auf 'IMAGE', was darauf hinweist, dass
ein eigenständiges Installationsimage erstellt wird.
- **modulepath**: Definiert den Pfad zu Java-Modulen und deren Abhängigkeiten, was für Anwendungen, die Java-Module
verwenden, unerlässlich ist.
- **addmodules**: Listet zusätzliche JavaFX-Module auf, die eingefügt werden sollen, um sicherzustellen, dass
alle GUI-Komponenten korrekt funktionieren.
- **mainclass**: Legt den Einstiegspunkt der Anwendung fest, der der vollständig qualifizierte Name der Hauptklasse ist.
- **input**: Weist auf das Verzeichnis hin, das die kompilierten Module und Abhängigkeiten enthält.
- **mainjar**: Gibt die Hauptausführbare JAR-Datei der Anwendung an.
Diese Einrichtung ist besonders nützlich, um einen reibungslosen, gestrafften Bereitstellungsprozess für JavaFX-Anwendungen zu schaffen, wodurch die Portabilität und die einfache Installation in verschiedenen Umgebungen verbessert wird.

68
documentation/de/MavenProject.md Normal file
View File

@ -0,0 +1,68 @@
# Erläuterung der Maven Projekt Datei (pom.xml)
Das Maven Projekt wird in einem XML Dokument beschrieben welches das Projekt Objekt Modell (pom) beschreibt.
## Rahmen der pom.xml
Der Anfang und die letzte Zeile eines jeden Maven Projekts ist eigentlich immer gleich.
In der ersten Zeile wird die Formatierung und das Encoding der Datei angegeben:
```
<?xml version="1.0" encoding="UTF-8"?>
```
Der oberste Knoten (und der modelVersion Knoten darunter) ist immer wie folgt:
```xml
<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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
</project>
```
In der Zukunft ändern die Entwickler ggf. etwas an dem Format, so dass sich die Modellversion ändert, aber bis dahin
bleiben diese Elemente unverändert.
## Eindeutige Identifizierung eines Projektes
Jedes Projekt sollte sich eindeutig über eine groupId, artefactId und version identifizieren lassen.
```xml
<groupId>de.kneitzel</groupId>
<artifactId>javafxapp</artifactId>
<version>1.0-SNAPSHOT</version>
```
**Wichtig**: Wenn Du das Template nutzt, solltest Du die bereits gesetzten Daten anpassen.
**Optional**: In dem Projekt kann auch die Organisation angegeben werden.
```xml
<organization>
<name>Java Forum</name>
</organization>
```
**Wichtig**: Bitte entferne diese Zeilen oder passe die Organisation an.
## Properties
Properties sind vergleichbar zu Variablen und können dazu genutzt werden, Dinge zusammen zu fassen, die sich
öfters ändern könnten.
Ich dem Template sind die Properties in mehrere Abschnitte unterteilt.
### Application properties
In diesem Abschnitt sind die Eigenschaften der Anwendung selbst zu finden. Dies können vorgegebene Namen sein
oder einfach der Klassenname der Hauptklasse zum Starten der Anwendung.
### Dependency versions
Alle Versionen von Abhängigkeiten der Anwendung werden in diesem Abschnitt gesammelt.
### Plugin versions
Die Versionen von Plugin finden sich in diesem Abschnitt.
### Other properties
Alles, was in keinen der bereits genannten Abschnitte fällt, findet sich dann in diesem Abschnitt.
Die Abschnitte, die danach kommen, werden in eigenständigen Dokumenten beschrieben und wären:
- **dependencies** Alle Abhängigkeiten der Anwendung werden hier aufgeführt.
- **build/plugins** Die Plugins mit ihrer Konfiguration finden sich in diesem Bereich
- **profiles** In dem Projekt nutze ich auch ein Profil zur Erstellung von Images.

61
documentation/de/PMD.md Normal file
View File

@ -0,0 +1,61 @@
# PMD
## Regeln für PMD konfigurieren
In dem Projekt verwenden wir PMD, um die Code-Qualität sicherzustellen und
um allgemeine Fehler zu vermeiden. Die Regeln für die Codeanalyse sind in
der Datei pmd-ruleset.xml definiert, die im Hauptverzeichnis des Projekts
liegt.
Diese Datei enthält spezifische Regelsätze, die an die Projektanforderungen
angepasst sind. Jeder Regelsatz innerhalb der pmd-ruleset.xml spezifiziert,
welche Probleme PMD im Code suchen und melden soll. Die Konfiguration umfasst
verschiedene Kategorien wie Fehlerprävention, Code-Stil, Optimierung und
viele andere.
Ein typischer Eintrag in dieser Datei sieht wie folgt aus:
```xml
<rule ref="category/java/bestpractices.xml/UnusedImports">
<priority>5</priority>
</rule>
```
In diesem Beispiel wird die Regel UnusedImports aus dem Bereich der Best
Practices verwendet, um ungenutzte Importe im Code zu identifizieren.
Die Priorität dieser Regel ist auf 5 gesetzt, was einer niedrigen Priorität
entspricht.
Um spezifische Bedürfnisse anzusprechen, können wir auch benutzerdefinierte
Regeln hinzufügen oder bestehende Regeln anpassen. Dies ermöglicht uns eine
flexible Anpassung der Codeanalyse, die dazu beiträgt, unseren Code sauber,
effizient und fehlerfrei zu halten.
Für die effektive Nutzung von PMD ist es wichtig, dass alle Teammitglieder
verstehen, wie die pmd-ruleset.xml aufgebaut ist und wie sie zur Verbesserung
der Codequalität beiträgt. Daher sollte jeder Entwickler mit dieser
Konfigurationsdatei vertraut sein und wissen, wie Änderungen daran vorgenommen
werden.
## Abbruch bei Regelverstößen
In dem Maven-Projekt können wir durch das Festlegen spezifischer Ziele (Goals)
des Maven PMD oder Checkstyle Plugins steuern, ob der Build-Prozess bei
Verstößen gegen festgelegte Regeln abgebrochen werden soll. Diese Funktion
ist besonders nützlich, um die Code-Qualität sicherzustellen und Fehler
frühzeitig im Entwicklungsprozess zu erkennen.
Je nach Konfiguration des Projekts können diese Ziele bei PMD gewählt werden:
- **pmd**: Bei Verstößen wird der weitere Build Prozess nicht abgebrochen
- **check**: Strengere Überprüfung und der Build Prozess bricht bei Vertsößen ab.
Damit dies direkt in den Properties konfiguriert werden kann, wird die
Property pmd.target verwendet:
```xml
<pmd.target>pmd</pmd.target>
```
## Ergebnis der Analyse
Das Ergebnis der Analyse findet sich nach der Überprüfung in target/pmd.xml.
Um die Datei besser lesen zu können, sollte man sich die Datei einfach
von der Entwicklungsumgebung formatieren lassen.

57
documentation/de/QuickStart.md Normal file
View File

@ -0,0 +1,57 @@
# Schnellstart
- Lade einfach das Projekt als ZIP Datei von GitHub und entpacke es an einer
Stelle Deiner Wahl auf dem Computer.
- Öffne die pom.xl und ändere die Einstellungen am Anfang des Dokumentes.
**Hinweis**: Im folgenden werden die Befehle für Unix artige Systeme / macos
angegeben. Unter Windows kannst Du am Anfang des Befehles das ./mvnw durch mvnw
ersetzen.
**Hinweis**: Die Befehle müssen im Hauptverzeichnis des Projekts, in dem auch
die pom.xml ist, ausgeführt werden.
## Wie kannst Du das Projekt nutzen
### Start der Anwendung von der Kommandozeile
```./mvnw javafx:run```
### Projekt bereinigen
Um das Projekt zu bereinigen, kannst Du
```./mvnw clean```
aufrufen.
### Übersetzen der Anwendung (Ohne ein Image zur Weitergabe zu bauen)
Um die Anwendung zu übersetzen kannst Du aufrufen:
```./mvnw package```
### Bau des Images zur Weitergabe
Um das Image zu bauen, rufst du einfach Maven mit dem Profil Image und dem
Ziel install auf:
```./mvnw -Dimage install```
**Wichtig** Du kannst nicht das JavaFX Plugin mit dem Ziel javafx:jlink verwenden,
da dieses Plugin zwingend eine Modulbeschreibung für das Projekt und alle
Abhängigkeiten erfordert.
### Komplette Übersetzung des Projekts incl. Dokumentation
Mit dem folgenden Befehl lässt sich das ganze Projekt von grundauf neu übersetzen incl.
der Erstellung der HTML Dokumentation des Projektes:
```./mvnw -Dimage clean install site```
- **-Dimage** aktiviert das Profil image, das für den Bau des Application Images zuständig ist
- **clean** Mit dem Ziel clean wird am Anfang alles, was bereits ggf. schon an Übersetzungen vorhanden ist, entfernt wird.
- **install** Durch install wird das ganze Projekt gebaut incl. Unit Tests, statischer Codeanalyse, ...
- **site** Es wird die Dokumentation des Projektes gebaut.
## Ergebnisse der statischen Codeanalyse
Die Codeanalyse läuft automatisch beim Bau des Projektes und die Ergebnisse
finden sich in:
- ./target/pmd.xml
- ./target/spotbugsXml.xml
Wenn die Site gebau wird, dann gibt es html Seiten mit den Ergebnissen von PMD und Spotbugs in der Site.

74
documentation/de/SpotBugs.md Normal file
View File

@ -0,0 +1,74 @@
# SpotBugs
## Verwendung der "null" Annotations
In Java-Projekten ist es wichtig, potenzielle NullPointer-Exceptions zu
vermeiden, die durch den unsachgemäßen Umgang mit Null-Werten entstehen
können. Die Null Annotations von JetBrains bieten eine praktische Lösung,
um solche Probleme frühzeitig im Code zu erkennen und entsprechende Warnungen
über Tools wie Spotbugs zu erhalten.
### Abhängigkeit
Die notwendigen Annotations sind u.a. in der Library von JetBrains
```xml
<dependency>
<groupId>org.jetbrains</groupId>
<artifactId>annotations</artifactId>
<version>${jetbrains.annotations.version</version>
<scope>compile</scope>
</dependency>
```
### Verwendung der Annotations im Code
Nachdem die Bibliothek in deinem Projekt verfügbar ist, kannst du die
Annotations **@Nullable** und **@NotNull** verwenden, um anzugeben, ob eine
Methode oder Variable Null-Werte akzeptieren darf oder nicht.
#### @NotNull
Die @NotNull Annotation wird verwendet, um anzugeben, dass ein Parameter,
eine lokale Variable, ein Feld oder eine Methode niemals den Wert null
annehmen sollte. Dies ist besonders wichtig in Methoden, die keine null
Werte verarbeiten können, da es andernfalls zu einer NullPointerException
führen könnte. Durch die Anwendung dieser Annotation kann deine
Entwicklungsumgebung oder ein statischer Code-Analyse-Tool wie SpotBugs oder
IntelliJ IDEA's integrierter Inspektor dich warnen, wenn es eine potenzielle
Verletzung dieser Bedingung gibt.
**Anwendungsbeispiele für @NotNull:**
- Methodenparameter: Garantiert, dass übergebene Argumente nicht null sind.
- Methodenrückgabetyp: Stellt sicher, dass die Methode keinen null Wert zurückgibt.
- Felder: Verhindert, dass Klassenfelder auf null gesetzt werden.
#### @Nullable
Die @Nullable Annotation wird verwendet, um zu kennzeichnen, dass eine
Variable, ein Parameter, ein Feld oder eine Methode null zurückgeben oder
null akzeptieren kann. Diese Annotation ist nützlich, um klarzustellen, dass
Methoden und Variablen sicher für den Umgang mit Nullwerten sind. Wenn eine
Variable oder Methode als @Nullable gekennzeichnet ist, sollten Entwickler
entsprechende Null-Checks durchführen, um NullPointerExceptions zu vermeiden.
**Anwendungsbeispiele für @Nullable:**
- Methodenparameter: Erlaubt explizit, dass übergebene Argumente null sein können.
- Methodenrückgabetyp: Gibt an, dass die Methode möglicherweise null zurückgibt, und fordert den Aufrufer auf, dies zu überprüfen.
- Felder: Erlaubt, dass Klassenfelder auf null gesetzt werden können.
### Allgemeine Richtlinien
**Konsistente Verwendung**: Es ist wichtig, diese Annotationen konsistent im
gesamten Code zu verwenden, um ihre Effektivität zu maximieren.
Inkonsistenzen können zu Fehlinterpretationen und Fehlern führen.
**Integration mit Tools**: Nutze Entwicklungswerkzeuge und statische
Code-Analyse-Tools, die diese Annotationen erkennen und respektieren
können, um die Sicherheit deines Codes zu erhöhen.
**Dokumentation und Team-Kommunikation**: Stelle sicher, dass alle
Teammitglieder die Bedeutung und den korrekten Einsatz dieser Annotationen
verstehen. Dies verbessert die Code-Qualität und verhindert Fehler in der
Zusammenarbeit.
Durch den durchdachten Einsatz von @NotNull und @Nullable kannst du die Robustheit deines Codes signifikant steigern und sicherstellen, dass deine Anwendungen weniger anfällig für Laufzeitfehler durch unerwartete Null-Werte sind.
## Ergebnis der Analyse
Das Ergebnis der Analyse findet sich nach der Überprüfung in target/spotbugsXml.xml.
Um die Datei besser lesen zu können, sollte man sich die Datei einfach
von der Entwicklungsumgebung formatieren lassen.

71
documentation/de/StaticCodeAnalysis.md Normal file
View File

@ -0,0 +1,71 @@
# Statische Codeanalyse
Statische Codeanalyse ist ein unerlässliches Werkzeug im Softwareentwicklungsprozess,
das dazu dient, Codequalität zu sichern und Fehler frühzeitig zu erkennen, bevor sie in
Produktion gehen. Sie analysiert den Quellcode auf potenzielle Fehler, ohne das Programm
auszuführen. Diese Technik ist besonders nützlich, um gängige Fehler wie Syntaxfehler,
Typinkonsistenzen oder ungenutzte Variablen aufzuspüren.
Der Hauptvorteil der statischen Codeanalyse liegt in ihrer Fähigkeit, komplexe und schwer
zu findende Fehler zu identifizieren, die während der Laufzeit schwer zu diagnostizieren
sind. Sie verbessert die Code-Sicherheit, indem sie Schwachstellen aufdeckt, die zu
Sicherheitslücken führen können, wie z.B. Buffer Overflows oder SQL-Injection. Darüber
hinaus unterstützt sie die Einhaltung von Kodierungsstandards und verbessert die Lesbarkeit
sowie Wartbarkeit des Codes.
Die Implementierung einer statischen Analyse in den Entwicklungszyklus ermöglicht es
Entwicklerteams, effizienter zu arbeiten, da viele Fehler behoben werden können, bevor sie
überhaupt in den Testprozess gelangen. Dies spart Zeit und Ressourcen in späteren
Entwicklungsphasen und führt zu einer insgesamt höheren Softwarequalität.
## Tools zur statischen Codeanalyse
### Sonarlint
SonarLint ist ein leistungsstarkes Plug-in für die statische Codeanalyse, das
für eine Vielzahl der am weitesten verbreiteten Entwicklungsumgebungen
verfügbar ist, darunter IDEs wie Eclipse, Visual Studio, IntelliJ IDEA und
Visual Studio Code. Dies ermöglicht es Entwicklern, Code-Qualitätsprobleme
direkt während der Entwicklung zu identifizieren und zu beheben, unabhängig
von der verwendeten Plattform.
Die Stärke von SonarLint liegt in seiner Fähigkeit, präzise und relevante
Ergebnisse zu liefern, was es zu einem wertvollen Werkzeug für
Softwareentwickler macht, die die Qualität ihrer Codebasis verbessern möchten.
Die Analyseergebnisse sind in der Regel sehr genau und helfen, Fehler
frühzeitig im Entwicklungsprozess zu erkennen und zu korrigieren.
SonarLint wird von SonarSource bereitgestellt, dem Unternehmen, das auch die
beliebte Code-Qualitätsplattform SonarQube entwickelt hat. Es ist unter einer
Open-Source-Lizenz verfügbar, was bedeutet, dass es kostenlos genutzt werden
kann, sowohl in kommerziellen als auch in nicht-kommerziellen Projekten.
Diese Lizenzierung macht SonarLint besonders attraktiv für Entwickler und
Organisationen, die eine kosteneffektive Lösung zur Verbesserung ihrer
Code-Qualität suchen.
### PMD
PMD ist ein beliebtes Tool für die statische Codeanalyse, das speziell darauf
ausgelegt ist, im Build-Prozess automatisch integriert zu werden. Dies
ermöglicht es, PMD nahtlos in kontinuierliche Integrationsumgebungen und auf
Buildservern zu verwenden. Durch seine Integration in den Build-Prozess kann
PMD automatisch Codeanalysen durchführen, sobald der Code kompiliert wird,
was die Identifikation und Behebung von Codequalitätsproblemen effizienter
gestaltet. Dies macht es zu einem idealen Werkzeug für Entwicklerteams, die
eine kontinuierliche Überwachung und Verbesserung der Codequalität
sicherstellen möchten.
### SpotBugs
SpotBugs ist ein fortschrittliches Werkzeug zur statischen Codeanalyse, das
speziell für die Integration in den Build-Prozess konzipiert ist, ähnlich wie
PMD, jedoch mit erweiterten Funktionen zur Erkennung potenzieller Fehler. Ein
besonderes Merkmal von SpotBugs ist die Unterstützung von Null-Überprüfungen
durch Annotationen wie @Nullable, die PMD nicht bietet. Diese Funktionalität
ermöglicht es Entwicklern, explizit anzugeben, wo Nullwerte erwartet werden,
was die Fähigkeit des Tools erhöht, Nullzeigerausnahmen zu erkennen, bevor
der Code bereitgestellt wird. Wie PMD kann auch SpotBugs nahtlos in
kontinuierliche Integrationsumgebungen und auf Buildservern integriert werden,
was den Prozess der Qualitätskontrolle des Codes während der Kompilierung
automatisiert. Diese Integration hilft Entwicklungsteams, durch
kontinuierliche Bewertungen und Verbesserungen einen hohen Standard der
Codequalität aufrechtzuerhalten.

16
documentation/de/_Index.md Normal file
View File

@ -0,0 +1,16 @@
# Übersicht über die Dokumentation
- [Schnellstart](QuickStart.md)
## Maven Projekt
- [Übersicht über das Maven Projekt](MavenProject.md)
- [Erzeugung eines Images](ImageCreation.md)
- Überprüfung auf Aktualisierungen
## [Statische Codeanalyse](StaticCodeAnalysis.md)
- [PMD](PMD.md)
- [SpotBugs](SpotBugs.md)
## Sonstiges
- Reporting
- Lombok

201
documentation/en/ImageCreation.md Normal file
View File

@ -0,0 +1,201 @@
# Image Creation
If the application is to be distributed, the translated program and possibly installation instructions are required.
Creating the image involves two steps:
Provision of all necessary files. This includes the translated classes and the application's resources, as well as all dependencies.
Creation of an "image": A directory structure with files along with a binary that can be executed.
## Invocation
To build the image, start Maven with the Image profile and the install goal.
Since there are sometimes problems when files need to be overwritten, a clean should be run first.
This can be done in one run:
```shell
mvnw -PImage clean install
```
## Description of theImage Profile
### The Profile
```xml
<profile>
<id>Image</id>
<activation>
<property>
<name>Image</name>
</property>
</activation>
<build>
<plugins>
<!-- ... -->
</plugins>
</build>
</profile>
```
- The profile has an ID: Image. This allows the profile to be selected using -PImage.
- Additionally, the profile can be selected using a define: -DImage
- The profile itself then contains plugins.
### maven-dependency-plugin
```xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>${maven.dependency.plugin}</version>
<executions>
<!-- erstmal Abhängigkeiten für den Class-Path kopieren -->
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/modules</outputDirectory>
<includeScope>runtime</includeScope>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>false</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
</execution>
<!-- dazu noch das Projekt-JAR -->
<execution>
<id>copy</id>
<phase>install</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/modules</outputDirectory>
<artifactItems>
<artifactItem>
<groupId>${project.groupId}</groupId>
<artifactId>${project.artifactId}</artifactId>
<version>${project.version}</version>
<type>${project.packaging}</type>
<destFileName>${project.build.finalName}.jar</destFileName>
</artifactItem>
</artifactItems>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
</execution>
</executions>
</plugin>
```
The Maven Dependency Plugin is used to copy the required files. This is done in two steps:
1. All dependencies are copied.
2. The produced artifact (the jar file with the project code) is copied.
#### copy-dependencies
The copy-dependencies execution within the maven-dependency-plugin is designed to automate the process of copying all
necessary runtime dependencies into a specified output directory. This execution is vital for ensuring that all runtime
components required by the application are available in the deployment environment. The configuration ensures that
dependencies are handled efficiently during the package phase of the build process.
Key aspects of the copy-dependencies execution include:
- **Phase**: It is configured to run during the package phase, which is the ideal time to gather all dependencies needed
for the packaged application.
- **Goals**: The copy-dependencies goal is utilized to perform the action of copying dependencies.
- **Configuration**: Important configuration settings include:
- - **outputDirectory**: Specifies the directory where all dependencies will be copied, typically a subdirectory in the
build directory such as /modules.
- - **includeScope**: Set to runtime to ensure that only dependencies needed at runtime are included, which helps in
reducing the size and complexity of the deployment.
- - **overWriteReleases, overWriteSnapshots, and overWriteIfNewer**: These settings manage how existing files in the
target directory are handled. They prevent overwriting of stable release versions and snapshot versions unless a newer
version is being copied, which helps in maintaining the integrity and up-to-dateness of the dependency files.
This configuration ensures that all necessary dependencies are prepared and available in the correct location before the application is packaged, facilitating a smooth transition to the assembly and deployment stages.
#### copy project artefact
The copy project artifact execution in the maven-dependency-plugin is tailored to facilitate the copying of the final
project artifact, typically the executable JAR file, into a designated output directory. This step is critical as it
ensures that the most current and verified version of the application is available for packaging and deployment.
Key aspects of the copy project artifact execution include:
- **Phase**: Configured to execute during the install phase, which follows the build and verification processes.
This timing is crucial to ensure that only fully built and tested artifacts are moved forward in the deployment pipeline.
- **Goals**: Utilizes the copy goal to perform the file copying operation.
- **Configuration**: Important configuration settings include:
- - **outputDirectory**: Specifies the destination directory where the project's JAR file will be placed, typically
within the build directory under /modules.
- - **artifactItems**: A list detailing the specific project artifacts to copy. This includes:
- - - **groupId, artifactId, version, and type**: These attributes uniquely identify the project artifact within the Maven
repository, ensuring the correct file is selected.
- - - **destFileName**: Specifies the name of the file as it should appear in the output directory. This allows for
customization of the output filename, which can be particularly useful in maintaining version control or distinguishing
between different builds.
- - **overWriteIfNewer**: Ensures that an existing file is only overwritten if the new file is more recent, which helps
in managing multiple versions and ensuring that the deployment always uses the most up-to-date artifact.
This setup ensures that the project artifact is correctly copied to the appropriate location, maintaining the integrity and readiness of the application for deployment. It provides a robust mechanism for managing the artifacts in a build pipeline, aligning with best practices for continuous integration and delivery.
### jpackage-maven-plugin
```xml
<plugin>
<groupId>com.github.akman</groupId>
<artifactId>jpackage-maven-plugin</artifactId>
<version>${jpackage.maven.plugin}</version>
<configuration>
<name>${appName}</name>
<type>IMAGE</type>
<modulepath>
<dependencysets>
<dependencyset>
<includenames>
<includename>javafx\..*</includename>
</includenames>
</dependencyset>
</dependencysets>
</modulepath>
<addmodules>
<addmodule>javafx.controls</addmodule>
<addmodule>javafx.graphics</addmodule>
<addmodule>javafx.fxml</addmodule>
<addmodule>javafx.web</addmodule>
</addmodules>
<mainclass>${main.class}</mainclass>
<input>${project.build.directory}/modules</input>
<mainjar>${jar.filename}.jar</mainjar>
</configuration>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>jpackage</goal>
</goals>
</execution>
</executions>
</plugin>
```
The jpackage-maven-plugin facilitates the creation of a self-contained application image using Java's JPackage
tool, which is part of the JDK. This plugin is configured to run during the 'install' phase of the Maven build
lifecycle. It bundles the application along with its dependencies and the Java runtime into a platform-specific
package, making it easier to distribute and deploy.
Key configurations for this plugin include:
- **Name and Type**: Specifies the application's name and sets the package type to 'IMAGE', indicating a standalone
installation image is created.
- **Module Path**: Defines the path to Java modules and their dependencies, essential for applications that use Java modules.
- **Additional Modules**: Lists extra JavaFX modules to include, ensuring all GUI components function correctly.
- **Main Class**: Sets the entry point of the application, which is the fully qualified name of the main class.
- **Input Directory**: Points to the directory containing the compiled modules and dependencies.
- **Main JAR**: Specifies the main executable JAR file of the application.
This setup is particularly useful for creating a smooth, streamlined deployment process for JavaFX applications,
enhancing portability and ease of installation across different environments.

70
documentation/en/MavenProject.md Normal file
View File

@ -0,0 +1,70 @@
# Explanation of the Maven Project file (pom.xml)
The Maven Project is described inside a XML document which describes the Project Object Model (pom).
## Start of the pom.xml
The first line defines the format and encoding of the file:
```
<?xml version="1.0" encoding="UTF-8"?>
```
The top node (+ modelVersion node) of the XML document is the project node should currently always be:
```xml
<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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
</project>
```
Maybe in the future the maven project will change the project object model in which case we might want to update
the given xsd and modelVersion.
## Unique identification of project
Each project should identify itself using a groupId, artefactId and version
```xml
<groupId>de.kneitzel</groupId>
<artifactId>javafxapp</artifactId>
<version>1.0-SNAPSHOT</version>
```
**Important**: You should change these values to something that is unique to you (and your organisation) so
that there will never be two projects with the same identification.
**Optional**: You can name your organization if you want to.
```xml
<organization>
<name>Java Forum</name>
</organization>
```
**Please** remove these lines or change them to your organization.
## Properties
Properties are like variables which could be used to have everything, that is quite likely to change, in one location.
In my project, I grouped the properties in multiple areas:
### Application specific properties
In this group I specify everything that is application specific: What names should be used?
Which class is the main class? And so on.
### Dependency versions
All versions of dependencies are stored in this area. That way it is easy to use one version multiple times
and it is easay to change these
### Plugin versions
All plugin versions are stored in this area.
### Other properties
Everything that does not fit in the other areas is placed in here e.g. encoding of files.
The next big areas does not need to be changed to start with the project. Of course: You might want to add dependencies
or other plugins later during development.
The following blocks will be described in detail later:
- **dependencies** with a list of all dependencies.
- **build/plugins** with all plugins used by this project, including their configuration.
- **profiles** We are using a profile. That way, we do not build the image every time we build the project.

61
documentation/en/PMD.md Normal file
View File

@ -0,0 +1,61 @@
# PMD
## Rules for PMD
In this project, we use PMD to ensure code quality and prevent common
mistakes. The rules for code analysis are defined in the pmd-ruleset.xml
file located in the main directory of the project.
This file contains specific rule sets tailored to the project requirements.
Each rule set within the pmd-ruleset.xml specifies what issues PMD should
look for and report in the code. The configuration includes various
categories such as error prevention, code style, optimization, and many
others.
A typical entry in this file looks like this:
```xml
<rule ref="category/java/bestpractices.xml/UnusedImports">
<priority>5</priority>
</rule>
```
In this example, the UnusedImports rule from the best practices category is
used to identify unused imports in the code. The priority of this rule is set
to 5, which indicates a low priority.
To address specific needs, we can also add custom rules or modify existing
ones. This allows us a flexible adjustment of the code analysis, which helps
to keep our code clean, efficient, and error-free.
For effective use of PMD, it is important that all team members understand
how the pmd-ruleset.xml is structured and how it contributes to improving
code quality. Therefore, every developer should be familiar with this
configuration file and know how to make changes to it.
## Stop build process on rule violations
In the Maven project, we can control whether the build process should be
aborted upon violations of specified rules by setting specific goals (Goals)
of the Maven PMD or Checkstyle plugins. This function is particularly useful
for ensuring code quality and detecting errors early in the development
process.
Depending on the project configuration, these goals can be selected for PMD:
- **pmd**: Violations do not cause the build process to be aborted
- **check**: Stricter verification and the build process is aborted upon
violations.
To enable configuration directly in the properties, the pmd.target property is used:
```xml
<pmd.target>pmd</pmd.target>
```
## Result of Analysis
The result can be found inside target/pmd.xml.
Formatting the file will make it much easier to read.

49
documentation/en/QuickStart.md Normal file
View File

@ -0,0 +1,49 @@
# Quick Start
- Simply download a zip file of this project and unzip it somewhere on your computer
- open the pom.xml and change the settings at the start of the document to fit with your project
**Important** The shown commands use a syntax that is used by unix and macos. If you
are using Windows then please replace the ./mvnw with mvnw only.
**Important** All commands shown should be issued in the root directoy of the project (the directory where you find the pom.xml)
## How to use this project
### Start the application from commandline
```./mvnw javafx:run```
### Clean up
To clean up the project, call
```./mvnw clean```
### build the application (Without building the application image)
To build the application, maven / the maven wrapper can be used. Simply do a
```./mvnw package```
to build the application.
(simply call mvnw instead of ./mvnw on windows!)
### Build the Image
To build the image, the profile Image must be used:
```./mvnw -Dimage install```
**Important** You cannot build an image using the javafx plugin. The javafx plugin requires that you build a modular
Java application and all dependencies providing a module description.
### complete build including documentation
To build the complete project from scratch and build all parts possible, you could use the following command:
```./mvnw -Dimage clean install site```
- **-Dimage** activates the profile image that is responsible to build the application image
- **clean** cleans everything of previous builds.
- **install** build the project (compile, build jar file, ...)
- **site** creates the html documentation of the project
## Static code analysis results
The static code analysis is done during the build of the application. The results can be found in
- ./target/pmd.xml
- ./target/spotbugsXml.xml

73
documentation/en/SpotBugs.md Normal file
View File

@ -0,0 +1,73 @@
# SpotBugs
## Using "null" Annotations
In Java projects, it's important to avoid potential NullPointerExceptions
that can arise from improper handling of null values. JetBrains' Null
Annotations offer a practical solution to detect such issues early in the
code and receive corresponding warnings through tools like SpotBugs.
### Dependency
The necessary annotations are included in the JetBrains library:
```xml
<dependency>
<groupId>org.jetbrains</groupId>
<artifactId>annotations</artifactId>
<version>${jetbrains.annotations.version}</version>
<scope>compile</scope>
</dependency>
```
### Using the Annotations in Code
Once the library is available in your project, you can use the **@Nullable**
and **@NotNull** annotations to indicate whether a method or variable can
accept null values.
#### @NotNull
The @NotNull annotation is used to specify that a parameter, local variable,
field, or method should never accept a null value. This is especially
important in methods that cannot process null values, as it could lead to a
NullPointerException. By using this annotation, your development environment
or a static code analysis tool like SpotBugs or IntelliJ IDEA's integrated
inspector can warn you if there's a potential violation of this condition.
**Examples of using @NotNull:**
- Method parameters: Ensures that passed arguments are not null.
- Method return types: Ensures that the method does not return a null value.
- Fields: Prevents class fields from being set to null.
#### @Nullable
The @Nullable annotation is used to indicate that a variable, parameter,
field, or method can return or accept null. This annotation is useful to
clarify that methods and variables are safe for handling null values. If a
variable or method is marked as @Nullable, developers should perform
appropriate null checks to avoid NullPointerExceptions.
**Examples of using @Nullable:**
- Method parameters: Explicitly allows passed arguments to be null.
- Method return types: Indicates that the method may return null, prompting the caller to check.
- Fields: Allows class fields to be set to null.
### General Guidelines
**Consistent Use**: It's important to use these annotations consistently
throughout the code to maximize their effectiveness. Inconsistencies can lead
to misinterpretations and errors.
**Integration with Tools**: Use development tools and static code analysis
tools that can recognize and respect these annotations to enhance your code's
safety.
**Documentation and Team Communication**: Ensure that all team members
understand the importance and correct use of these annotations. This improves
code quality and prevents errors in collaboration.
By thoughtfully using @NotNull and @Nullable, you can significantly enhance
the robustness of your code and ensure that your applications are less
susceptible to runtime errors caused by unexpected null values.
## Result of Analysis
The result can be found inside target/spotbugsXml.xml.
Formatting the file will make it much easier to read.

65
documentation/en/StaticCodeAnalysis.md Normal file
View File

@ -0,0 +1,65 @@
# Static Code Analysis
Static code analysis is an essential tool in the software development process,
designed to ensure code quality and detect errors early before they go into
production. It examines the source code for potential mistakes without running
the program. This technique is particularly useful for identifying common
errors such as syntax errors, type inconsistencies, or unused variables.
The main advantage of static code analysis lies in its ability to identify
complex and hard-to-find errors that are difficult to diagnose during runtime.
It enhances code security by revealing vulnerabilities that could lead to
security breaches, such as buffer overflows or SQL injection. Additionally,
it supports adherence to coding standards and improves the readability and
maintainability of the code.
Implementing static analysis in the development cycle allows development
teams to work more efficiently, as many errors can be addressed before they
even enter the testing process. This saves time and resources in later
development stages and leads to overall higher software quality.
## Tools for static code analysis
### Sonarlint
SonarLint is a powerful static code analysis plugin available for a wide
range of widely-used development environments, including IDEs like Eclipse,
Visual Studio, IntelliJ IDEA, and Visual Studio Code. This enables developers
to identify and fix code quality issues directly during the development
process, regardless of the platform used.
The strength of SonarLint lies in its ability to deliver precise and relevant
results, making it a valuable tool for software developers looking to improve
the quality of their codebase. The analysis results are typically very
accurate and help to detect and correct errors early in the development
process.
SonarLint is provided by SonarSource, the company that also developed the
popular code quality platform SonarQube. It is available under an open-source
license, meaning it can be used free of charge in both commercial and
non-commercial projects. This licensing makes SonarLint particularly
attractive for developers and organizations seeking a cost-effective
solution to enhance their code quality.
### PMD
PMD is a popular static code analysis tool specifically designed to be
automatically integrated into the build process. This allows PMD to be
seamlessly used in continuous integration environments and on build servers.
By being integrated into the build process, PMD can automatically perform
code analysis as soon as the code is compiled, making the identification
and resolution of code quality issues more efficient. This makes it an
ideal tool for development teams that want to ensure continuous monitoring
and improvement of code quality.
### SpotBugs
SpotBugs is an advanced static code analysis tool tailored for integration
into the build process, similar to PMD, but with enhanced capabilities for
identifying potential bugs. A distinctive feature of SpotBugs is its support
for null-checks using annotations such as @Nullable, which PMD does not offer.
This functionality allows developers to explicitly denote where null values
are expected, enhancing the tool’s ability to detect null pointer exceptions
before the code is deployed. Like PMD, SpotBugs can be seamlessly integrated
into continuous integration environments and on build servers, automating the
process of code quality checks during compilation. This integration aids
development teams in maintaining high standards of code quality through
continuous assessments and improvements.

16
documentation/en/_Index.md Normal file
View File

@ -0,0 +1,16 @@
# Documentation Overview
- [Quick Start](QuickStart.md)
## Maven Project
- [Maven Project Overview](MavenProject.md)
- [Image Creation](ImageCreation.md)
- Checking of Updates
## [Static Code Analysis](StaticCodeAnalysis.md)
- [PMD](PMD.md)
- [SpotBugs](SpotBugs.md)
## Other Topics
- Reporting
- Lombok

113
pom.xml
View File

@ -30,6 +30,9 @@
<mockito.version>5.11.0</mockito.version>
<!-- Plugin dependencies -->
<codehaus.version.plugin>2.16.2</codehaus.version.plugin>
<javafx.maven.plugin>0.0.8</javafx.maven.plugin>
<jpackage.maven.plugin>0.1.5</jpackage.maven.plugin>
<maven.clean.plugin>3.3.2</maven.clean.plugin>
<maven.compiler.plugin>3.13.0</maven.compiler.plugin>
<maven.dependency.plugin>3.6.1</maven.dependency.plugin>
@ -37,18 +40,19 @@
<maven.enforcer.plugin>3.4.1</maven.enforcer.plugin>
<maven.install.plugin>3.1.2</maven.install.plugin>
<maven.jar.plugin>3.4.1</maven.jar.plugin>
<maven.javadoc.plugin>3.6.3</maven.javadoc.plugin>
<maven.project.info.reports.plugin>3.5.0</maven.project.info.reports.plugin>
<maven.resources.plugin>3.3.1</maven.resources.plugin>
<maven.site.plugin>4.0.0-M13</maven.site.plugin>
<maven.site.plugin>4.0.0-M14</maven.site.plugin>
<maven.surfire.plugin>3.2.5</maven.surfire.plugin>
<moditect.maven.plugin>1.0.0.RC2</moditect.maven.plugin>
<jpackage.maven.plugin>0.1.5</jpackage.maven.plugin>
<maven.pmd.version>3.22.0</maven.pmd.version>
<codehaus.version.plugin>2.16.2</codehaus.version.plugin>
<javafx.maven.plugin>0.0.8</javafx.maven.plugin>
<maven.pmd.plugin>3.22.0</maven.pmd.plugin>
<spotbugs.maven.plugin>4.8.5.0</spotbugs.maven.plugin>
<spotbugs.version>4.8.5</spotbugs.version>
<!-- other properties -->
<pmd.target>pmd</pmd.target> <!-- Set to 'pmd' if pmd should not fail on issues. Set to 'check' if you want build to fail when issues found -->
<spotbugs.target>spotbugs</spotbugs.target> <!-- Set to 'spotbugs' if spotbugs should not fail on issues. Set to 'check' if you want build to fail when issues found -->
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>${java.version}</maven.compiler.source>
<maven.compiler.target>${java.version}</maven.compiler.target>
@ -226,11 +230,7 @@
<execution>
<phase>prepare-package</phase>
<goals>
<!-- spotbugs does not stop build when violations are found -->
<goal>spotbugs</goal>
<!-- check stops the build when violations are found -->
<!-- <goal>check</goal> -->
<goal>${spotbugs.target}</goal>
</goals>
</execution>
</executions>
@ -239,7 +239,7 @@
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>${maven.pmd.version}</version>
<version>${maven.pmd.plugin}</version>
<configuration>
<minimumTokens>100</minimumTokens>
<targetJdk>${java.version}</targetJdk>
@ -252,11 +252,7 @@
<execution>
<phase>prepare-package</phase>
<goals>
<!-- pmd target does not stop build when violations are found -->
<goal>pmd</goal>
<!-- check stops the build when violations are found -->
<!-- <goal>check</goal> -->
<goal>${pmd.target}</goal>
</goals>
</execution>
</executions>
@ -278,6 +274,20 @@
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>${maven.javadoc.plugin}</version>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- JavaFX Plugin to start application -->
<plugin>
<groupId>org.openjfx</groupId>
@ -290,17 +300,82 @@
</plugins>
</build>
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
<version>${maven.project.info.reports.plugin}</version>
<reportSets>
<reportSet>
<reports>
<report>index</report>
<report>dependencies</report>
<report>licenses</report>
<report>summary</report>
</reports>
</reportSet>
</reportSets>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>${maven.javadoc.plugin}</version>
<reportSets>
<reportSet>
<reports>
<report>javadoc</report>
</reports>
</reportSet>
<reportSet>
<id>tests</id>
<configuration>
<show>private</show>
</configuration>
<reports>
<report>test-javadoc</report>
</reports>
</reportSet>
</reportSets>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>${maven.pmd.plugin}</version>
<reportSets>
<reportSet>
<reports>
<report>pmd</report>
</reports>
</reportSet>
</reportSets>
</plugin>
<plugin>
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
<version>${spotbugs.maven.plugin}</version>
<reportSets>
<reportSet>
<reports>
<report>spotbugs</report>
</reports>
</reportSet>
</reportSets>
</plugin>
</plugins>
</reporting>
<profiles>
<!-- Profile that adds JLink and JPackage runs.
Add -PImage or -DImage to use this profile.
Add -Pimage or -Dimage to use this profile.
-->
<profile>
<id>Image</id>
<id>image</id>
<activation>
<property>
<name>Image</name>
<name>image</name>
</property>
</activation>
<build>