Update from template (auto-merged)

.config/pmd/ruleset.xml

@@ -59,6 +59,9 @@
 		<!-- Prohibits singleton pattern -->
 		<exclude name="MutableStaticState"/>
 
+		<!-- Checks LoC, already handled by Checkstyle -->
+		<exclude name="NcssCount"/>
+
 		<!-- Some override methods or Junit require this -->
 		<exclude name="SignatureDeclareThrowsException"/>
 

.github/workflows/test-deploy.yml

@@ -24,7 +24,7 @@ jobs:
         gpg-private-key: ${{ secrets.MAVEN_GPG_PRIVATE_KEY }}
 
     - name: Publish to OSSRH
-      run: ../mvnw -B deploy -Possrh
+      run: ../mvnw -B deploy -Possrh -DskipTests
       working-directory: ${{ env.PRIMARY_MAVEN_MODULE }}
       env:
         MAVEN_CENTRAL_USERNAME: ${{ secrets.S01_OSS_SONATYPE_MAVEN_USERNAME }}

CONTRIBUTING.md

@@ -44,3 +44,31 @@ If the ``develop`` is ready for release, create a pull request to the ``master``
 
 When the release is finished do the following:
 * Merge the auto-generated PR (with the incremented version number) back into the ``develop``
+
+### Release failures
+
+There are 2 modes of release failure:
+1. The remote server was e.g. down and non of the artifacts got published
+2. There was a build failure during release and only parts of the artifacts got released
+
+In case 1 we can re-release the existing version,<br/>in case 2 we have to release a new version when we can't get the artifacts deleted (as is the case with Maven Central)
+
+#### How-to: Re-Releasing an existing version
+
+1. Delete the release on GitHub
+2. Delete the release Git tag from the repo (locally and remote!)
+3. Delete the ``master``-Branch and re-create it from the ``develop`` branch (or reset it to the state before the release-workflow commits have been done)
+    * This requires __temporarily__ removing the branch protection
+    * Once this was done a new release is triggered immediately!
+
+#### How-to: Releasing a new version
+
+1. Merge the ``master`` branch back into ``develop`` (or another temporary branch)
+2. Make sure all master branch versions are prepared for a new release<br/>e.g. if the broken release was ``1.0.0`` the version should now be at ``1.0.1-SNAPSHOT`` - the ``SNAPSHOT`` is important for the workflow!
+3. Mark the broken release as broken e.g. inside the Changelog, GitHub Release page, etc.<br/>
+You can use something like this:
+    ```
+    > [!WARNING]
+    > This release is broken as my cat accidentally clicked the abort button during the process
+    ```
+4. Merge the changes back into the ``master`` branch to trigger a new release

chartjs-java-model/pom.xml

@@ -193,7 +193,7 @@
 				<plugin>
 					<groupId>org.apache.maven.plugins</groupId>
 					<artifactId>maven-project-info-reports-plugin</artifactId>
-					<version>3.6.1</version>
+					<version>3.6.2</version>
 				</plugin>
 			</plugins>
 		</pluginManagement>
@@ -385,7 +385,7 @@
 					<plugin>
 						<groupId>org.apache.maven.plugins</groupId>
 						<artifactId>maven-pmd-plugin</artifactId>
-						<version>3.23.0</version>
+						<version>3.24.0</version>
 						<configuration>
 							<includeTests>true</includeTests>
 							<printFailingErrors>true</printFailingErrors>

pom.xml

@@ -70,7 +70,7 @@
 					<plugin>
 						<groupId>org.apache.maven.plugins</groupId>
 						<artifactId>maven-pmd-plugin</artifactId>
-						<version>3.23.0</version>
+						<version>3.24.0</version>
 						<configuration>
 							<includeTests>true</includeTests>
 							<printFailingErrors>true</printFailingErrors>