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