Remove support for Java 17

.github/workflows/ci.yml

@@ -12,7 +12,7 @@ jobs:
     strategy:
       matrix:
         platform: [ubuntu-latest, macos-latest, windows-latest]
-        jdk: [17, 21, 25]
+        jdk: [21, 25]
 
     runs-on: ${{ matrix.platform }}
     name: on ${{ matrix.platform }} with JDK ${{ matrix.jdk }}

.github/workflows/codeql.yml

@@ -25,11 +25,11 @@ jobs:
     steps:
       - uses: actions/checkout@v5
 
-      - name: Setup Java
+      - name: Setup JDK
         uses: actions/setup-java@v5
         with:
           distribution: temurin
-          java-version: 21
+          java-version: 25
           cache: maven
 
       - name: Set up Maven

.github/workflows/quality-monitor-build.yml

@@ -11,11 +11,11 @@ jobs:
     steps:
       - name: Checkout PR
         uses: actions/checkout@v5
-      - name: Set up JDK 21
+      - name: Set up JDK
         uses: actions/setup-java@v5
         with:
           distribution: 'temurin'
-          java-version: 21
+          java-version: 25
           check-latest: true
           cache: 'maven'
       - name: Set up Maven

.github/workflows/update-badges.yml

@@ -13,11 +13,11 @@ jobs:
 
     steps:
       - uses: actions/checkout@v5
-      - name: Set up JDK 21
+      - name: Set up JDK
         uses: actions/setup-java@v5
         with:
           distribution: 'temurin'
-          java-version: '21'
+          java-version: '25'
           check-latest: true
           cache: 'maven'
       - name: Set up Maven

doc/Continuous-Integration.md

@@ -27,7 +27,7 @@ U. a. sind die folgenden Plugins vorkonfiguriert:
 
 Die Konfiguration der Continuous Integration in GitHub Actions ist sehr [einfach](../.github/workflows/ci.yml) über eine Pipeline möglich. 
 Da der gesamte Build über Maven automatisiert ist, besteht die Pipeline eigentlich nur aus einem Maven Aufruf, der das Projekt baut, alle Tests (Unit und Integrationstests) ausgeführt, die statische Code Analyse durchführt und schließlich die Coverage misst. 
-GitHub Actions bietet auch die Möglichkeit, Matrix Builds durchzuführen: D. h., der Build wird z. B. auf den Plattformen Linux, Windows und macOS oder mit den Java-Versionen 17 und 21 parallel durchgeführt. 
+GitHub Actions bietet auch die Möglichkeit, Matrix Builds durchzuführen: D. h., der Build wird z. B. auf den Plattformen Linux, Windows und macOS oder mit den Java-Versionen 21 und 25 parallel durchgeführt. 
 Ein Beispiel für die Konfiguration eines Matrix Builds ist in der Datei [ci.yml](../.github/workflows/ci.yml) zu finden.
 
 Wenn gewünscht, können die Ergebnisse der statischen Codeanalyse und der Code Coverage Tools auch direkt im Commit oder Pull-Request angezeigt werden. 

doc/Externe-Tool-Integration.md

@@ -5,31 +5,25 @@ Zur Unterstützung des Entwicklungsworkflows sind bereits verschiedene externe T
 ## Automatische Aktualisierung der Abhängigkeiten
 
 Die Abhängigkeiten des Projektes (Dependencies) werden über Maven verwaltet und sind im [POM](../pom.xml) konfiguriert.
-Um das Projekt immer auf dem laufenden Stand zu halten, ist die GitHub App [Dependabot](https://dependabot.com)
-aktiv geschaltet: diese prüft automatisch, on neue Versionen einer Bibliothek (oder eines Maven Plugins) zur Verfügung 
-stehen. Ist dies der Fall, erstellt der Roboter automatisch einen 
-[Pull Request](https://github.com/uhafner/codingstyle/pulls), der die Version aktualisiert.
+Um das Projekt immer auf dem laufenden Stand zu halten, ist die GitHub App [Dependabot](https://dependabot.com) aktiv geschaltet.
+Diese prüft automatisch, on neue Versionen einer Bibliothek (oder eines Maven Plugins) zur Verfügung stehen. 
+Ist dies der Fall, erstellt der Roboter automatisch einen [Pull Request](https://github.com/uhafner/codingstyle/pulls), der die Version aktualisiert.
 
 ## Automatisierte Generierung eines Changelog
 
-Damit der Nutzer des Projekts immer über alle Änderungen im Projekt im Bilde ist, ist die GitHub App 
-[Release Drafter](https://github.com/toolmantim/release-drafter) aktiviert. Diese erstellt automatisch neue Changelog
-Einträge im [GitHub Releases Bereich](https://github.com/uhafner/codingstyle/releases). Diese Einträge werden
-aus den Titeln der Pull Requests generiert, d.h. jede Änderung am Projekt sollte über Pull Requests erfolgen und nicht 
-über direkte Git Commits - dies entspricht auch dem Vorgehen des [GitHub Flows](https://guides.github.com/introduction/flow/).
+Damit die Nutzer des Projekts immer über alle Änderungen im Projekt im Bild sind, ist die GitHub App [Release Drafter](https://github.com/toolmantim/release-drafter) aktiviert. 
+Diese erstellt automatisch neue Changelog Einträge im [GitHub Releases Bereich](https://github.com/uhafner/codingstyle/releases). 
+Diese Einträge werden automatisch aus den Titeln der Pull Requests generiert, d. h. jede Änderung am Projekt sollte über Pull Requests erfolgen und nicht über direkte Git Commits – dies entspricht auch dem Vorgehen des [GitHub Flows](https://guides.github.com/introduction/flow/).
 
-## Statische Analyse von Pull Requests mit CheckStyle und PMD
+## Continuous Integration (inklusive Überwachung von Quality Gates)
 
-Wie bereits im Abschnitt [Continuous Integration](Continuous-Integration.md) erwähnt, gibt es keinen öffentlichen 
-Service, ein GitHub Projekt mit Jenkins automatisiert zu bauen. Für GitHub Actions gibt es diesen Service, aber 
-die Visualisierung der Ergebnisse der statischen Analyse wird leider nicht unterstützt. 
+Wie bereits im Abschnitt [Continuous Integration](Continuous-Integration.md) erwähnt, wird das Projekt bei jeder Änderung mit einer GitHub Pipeline automatisiert gebaut.
+Diese [Pipeline](https://github.com/uhafner/codingstyle/blob/main/.github/workflows/ci.yml) läuft auf Rechnern von GitHub und führt einen Build unter JDK 21 und 25 aus. 
+Aktuell wird der Build auf virtualisierten Rechnern der Betriebssysteme Linux, Windows und macOS durchgeführt.
+Anschließend werden die Build Ergebnisse mit meinem [Quality Monitor](https://github.com/uhafner/quality-monitor) analysiert.
+Dieser Service sammelt die Ergebnisse der statischen Code-Analyse (CheckStyle, PMD, SpotBugs) und der Code-Coverage (JaCoCo) und stellt diese als Kommentar im Pull Request dar.
+Anschließend werden die Quality Gates überprüft: Werden die definierten Qualitätskriterien nicht erfüllt, so schlägt der Build fehl.
 
-## Security Analyse von Pull Requests
+## Sicherheitsanalyse von Pull Requests
 
-Zusätzlich zur statischen Analyse wird ein Pull Request auf Sicherheitslücken untersucht. Dies erfolgt über die GitHub
-App [LGTM](https://lgtm.com).
-
-## Bewertung der Code Coverage 
-
-Die Code Coverage der Unit-Tests wird ebenfalls nach jeder Änderung (bzw. für jeden Pull Request) an den Service
-[Codecov](https://app.codecov.io/gh/uhafner/codingstyle) weitergeleitet, der die Resultate grafisch visualisiert.
+Zusätzlich zur statischen Analyse wird ein Pull Request auf Sicherheitslücken untersucht. Dies erfolgt über die GitHub App [CodeQL](https://codeql.github.com/).

pom.xml

@@ -48,6 +48,7 @@
     <source.encoding>UTF-8</source.encoding>
     <project.build.sourceEncoding>${source.encoding}</project.build.sourceEncoding>
     <java.version>17</java.version>
+    <java.jdk.version>21</java.jdk.version>
 
     <module.name>${project.groupId}.codingstyle</module.name>
 
@@ -721,7 +722,7 @@
             <configuration>
               <rules>
                 <requireJavaVersion>
-                  <version>${java.version}</version>
+                  <version>${java.jdk.version}</version>
                 </requireJavaVersion>
               </rules>
             </configuration>