Added reporting & updating documentation.

This commit is contained in:
Konrad Neitzel
2024-05-09 22:30:15 +02:00
parent d836e46a71
commit bbb7205095
13 changed files with 607 additions and 72 deletions
+43 -26
View File
@@ -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
@@ -146,26 +146,41 @@ This setup ensures that the project artifact is correctly copied to the appropri
### 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>
```
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
@@ -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
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.
+8 -3
View File
@@ -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
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
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.
+4 -3
View File
@@ -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