Added reporting & updating documentation.
This commit is contained in:
Konrad Neitzel
parent
d836e46a71
commit
bbb7205095
@ -11,25 +11,25 @@ werden kann.
|
||||
|
||||
## Aufruf
|
||||
|
||||
Um das Image zu bauen, ist Maven mit dem Profil Image und dem Ziel install zu starten.
|
||||
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
|
||||
mvnw -Pimage clean install
|
||||
```
|
||||
|
||||
## Beschreibung des Image Profils
|
||||
## Beschreibung des image Profils
|
||||
|
||||
### Das Profil
|
||||
|
||||
```xml
|
||||
<profile>
|
||||
<id>Image</id>
|
||||
<id>image</id>
|
||||
<activation>
|
||||
<property>
|
||||
<name>Image</name>
|
||||
<name>image</name>
|
||||
</property>
|
||||
</activation>
|
||||
<build>
|
||||
@ -42,8 +42,8 @@ mvnw -PImage clean install
|
||||
</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
|
||||
- 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
|
||||
@ -161,6 +161,21 @@ und Auslieferung orientiert.
|
||||
<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>
|
||||
@ -184,6 +199,10 @@ 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.
|
||||
|
||||
61
documentation/de/PMD.md
Normal file
61
documentation/de/PMD.md
Normal 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.
|
||||
@ -21,11 +21,17 @@ aufrufen.
|
||||
Um die Anwendung zu übersetzen kannst Du aufrufen:
|
||||
```./mvnw package```
|
||||
|
||||
### Bau des Images zur weitergabe
|
||||
### Bau des Application Images zur Weitergabe (JPackage)
|
||||
|
||||
Um das Image zu bauen, rufst du einfach Maven mit dem Profil Image und dem
|
||||
Um das Image mit JPackage zu bauen, rufst du einfach Maven mit dem Profil Image und dem
|
||||
Ziel install auf:
|
||||
```./mvnw -DImage install```
|
||||
```./mvnw -Dimage install```
|
||||
|
||||
### Bau des native Images zur Weitergabe (GraalVM)
|
||||
|
||||
Um das Image mit NativeImage / GraalVM zu bauen, rufst du einfach Maven mit dem Profil Image und dem
|
||||
Ziel install auf:
|
||||
```./mvnw -Dnative install```
|
||||
|
||||
## Ergebnisse der statischen Codeanalyse
|
||||
|
||||
|
||||
74
documentation/de/SpotBugs.md
Normal file
74
documentation/de/SpotBugs.md
Normal 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
71
documentation/de/StaticCodeAnalysis.md
Normal 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.
|
||||
@ -7,9 +7,10 @@
|
||||
- [Erzeugung eines Images](ImageCreation.md)
|
||||
- Überprüfung auf Aktualisierungen
|
||||
|
||||
# Statische Codeanalyse
|
||||
- PMD
|
||||
- SpotBugs
|
||||
## [Statische Codeanalyse](StaticCodeAnalysis.md)
|
||||
- [PMD](PMD.md)
|
||||
- [SpotBugs](SpotBugs.md)
|
||||
|
||||
# Sonstiges
|
||||
## Sonstiges
|
||||
- Reporting
|
||||
- Lombok
|
||||
@ -9,12 +9,12 @@ Creation of an "image": A directory structure with files along with a binary tha
|
||||
|
||||
## Invocation
|
||||
|
||||
To build the image, start Maven with the Image profile and the install goal.
|
||||
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
|
||||
mvnw -Pimage clean install
|
||||
```
|
||||
|
||||
## Description of theImage Profile
|
||||
@ -23,10 +23,10 @@ mvnw -PImage clean install
|
||||
|
||||
```xml
|
||||
<profile>
|
||||
<id>Image</id>
|
||||
<id>image</id>
|
||||
<activation>
|
||||
<property>
|
||||
<name>Image</name>
|
||||
<name>image</name>
|
||||
</property>
|
||||
</activation>
|
||||
<build>
|
||||
@ -39,8 +39,8 @@ mvnw -PImage clean install
|
||||
</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 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
|
||||
@ -153,6 +153,21 @@ This setup ensures that the project artifact is correctly copied to the appropri
|
||||
<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>
|
||||
@ -176,6 +191,8 @@ 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.
|
||||
|
||||
61
documentation/en/PMD.md
Normal file
61
documentation/en/PMD.md
Normal 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.
|
||||
@ -17,10 +17,15 @@ To build the application, maven / the maven wrapper can be used. Simply do a
|
||||
to build the application.
|
||||
(simply call mvnw instead of ./mvnw on windows!)
|
||||
|
||||
### Build the Image
|
||||
### Build the application Image (jpackage)
|
||||
|
||||
To build the image, the profile Image must be used:
|
||||
```./mvnw -DImage install```
|
||||
To build the image with jpackage, the profile image must be used:
|
||||
```./mvnw -Dimage install```
|
||||
|
||||
### Build the native Image (GraalVM)
|
||||
|
||||
To build the native image with GraalVM, the profile native must be used:
|
||||
```./mvnw -Dnative install```
|
||||
|
||||
## Static code analysis results
|
||||
|
||||
|
||||
73
documentation/en/SpotBugs.md
Normal file
73
documentation/en/SpotBugs.md
Normal 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
65
documentation/en/StaticCodeAnalysis.md
Normal 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.
|
||||
@ -7,9 +7,10 @@
|
||||
- [Image Creation](ImageCreation.md)
|
||||
- Checking of Updates
|
||||
|
||||
## Static Code Analysis
|
||||
- PMD
|
||||
- FindBugs
|
||||
## [Static Code Analysis](StaticCodeAnalysis.md)
|
||||
- [PMD](PMD.md)
|
||||
- [SpotBugs](SpotBugs.md)
|
||||
|
||||
## Other Topics
|
||||
- Reporting
|
||||
- Lombok
|
||||
93
pom.xml
93
pom.xml
@ -24,7 +24,6 @@
|
||||
<launcher>${project.artifactId}</launcher>
|
||||
<appName>${project.artifactId}</appName>
|
||||
<main.class>de.kneitzel.JavaApp</main.class>
|
||||
<main.module>AppModule</main.module>
|
||||
<java.version>21</java.version>
|
||||
<jar.filename>${project.artifactId}-${project.version}</jar.filename>
|
||||
|
||||
@ -45,9 +44,11 @@
|
||||
<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.pmd.plugin>3.22.0</maven.pmd.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>
|
||||
<native.maven.plugin>0.10.1</native.maven.plugin>
|
||||
@ -269,21 +270,101 @@
|
||||
<artifactId>maven-site-plugin</artifactId>
|
||||
<version>${maven.site.plugin}</version>
|
||||
</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>
|
||||
|
||||
</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 compiling to a native binary using
|
||||
GraalVM an Native Image https://www.graalvm.org/
|
||||
|
||||
Add -PGraalVM or -DGraalVM to use this profile.
|
||||
Add -Pnative or -Dnative to use this profile.
|
||||
-->
|
||||
<profile>
|
||||
<id>GraalVM</id>
|
||||
<id>native</id>
|
||||
<activation>
|
||||
<property>
|
||||
<name>GraalVM</name>
|
||||
<name>native</name>
|
||||
</property>
|
||||
</activation>
|
||||
<build>
|
||||
@ -323,7 +404,7 @@
|
||||
Add -PImage or -DImage to use this profile.
|
||||
-->
|
||||
<profile>
|
||||
<id>Image</id>
|
||||
<id>image</id>
|
||||
<activation>
|
||||
<property>
|
||||
<name>Image</name>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user