Template
Added reporting & updating documentation.
This commit is contained in:
Konrad Neitzel
@@ -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
|
||||
@@ -154,26 +154,41 @@ 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>
|
||||
<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>
|
||||
<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
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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.
|
||||
@@ -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
|
||||
Reference in New Issue
Block a user