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

Merge pull request #11 from kneitzel/UpdateDocumentation

Browse Source 
Update documentation
This commit is contained in:
Konrad Neitzel 2024-05-07 13:40:51 +02:00 committed by GitHub
commit 7201a660a3
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
6 changed files with 572 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
README.md
View File

@ -2,15 +2,18 @@
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**: 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
**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.
**Important** All commands following should be issued in the root directoy of the project (the directory where you find the pom.xml)
*Quick Start*
@ -21,31 +24,31 @@ This projects includes multiple plugins:
*How to use this project*
**build the application**
**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!)
**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
**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.
**Static code analysis**
**Static code analysis results**
The static code analysis is done when you build the application. The results can be found in
- ./target/pmx.xml
The static code analysis is done during the build of the application. The results can be found in
- ./target/pmd.xml
- ./target/spotbugsXml.xml

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.

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.

15
pom.xml
View File

@ -49,6 +49,8 @@
<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 +228,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>
@ -241,7 +239,6 @@
<artifactId>maven-pmd-plugin</artifactId>
<version>${maven.pmd.version}</version>
<configuration>
<sourceEncoding>${project.build.sourceEncoding}</sourceEncoding>
<minimumTokens>100</minimumTokens>
<targetJdk>${java.version}</targetJdk>
<linkXRef>false</linkXRef>
@ -253,11 +250,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>