Merge branch 'main' into csl-tests

.github/workflows/deployment-jdk-ea.yml

@@ -5,7 +5,7 @@ name: Deployment (JDK early access builds)
 
 on:
   schedule:
-    - cron: "0 5 * * 2"
+    - cron: "0 18 * * 1"
   pull_request:
     paths:
       - .github/workflows/deployment-jdk-ea.yml

build.gradle

@@ -29,7 +29,7 @@ plugins {
 
     id 'idea'
 
-    id 'org.openrewrite.rewrite' version '6.17.1'
+    id 'org.openrewrite.rewrite' version '6.20.0'
 }
 
 // Enable following for debugging
@@ -172,7 +172,7 @@ dependencies {
     implementation "org.apache.lucene:lucene-highlighter:$luceneVersion"
 
     implementation group: 'org.apache.commons', name: 'commons-csv', version: '1.11.0'
-    implementation group: 'org.apache.commons', name: 'commons-lang3', version: '3.15.0'
+    implementation group: 'org.apache.commons', name: 'commons-lang3', version: '3.16.0'
     implementation group: 'org.apache.commons', name: 'commons-text', version: '1.12.0'
     implementation 'commons-logging:commons-logging:1.3.3'
     implementation 'com.h2database:h2-mvstore:2.3.230'
@@ -236,7 +236,7 @@ dependencies {
     }
     implementation 'org.fxmisc.flowless:flowless:0.7.3'
     implementation 'org.fxmisc.richtext:richtextfx:0.11.3'
-    implementation (group: 'com.dlsc.gemsfx', name: 'gemsfx', version: '2.32.0') {
+    implementation (group: 'com.dlsc.gemsfx', name: 'gemsfx', version: '2.43.0') {
         exclude module: 'javax.inject' // Split package, use only jakarta.inject
         exclude module: 'commons-lang3'
         exclude group: 'org.apache.commons.validator'
@@ -297,7 +297,7 @@ dependencies {
     // API
     implementation 'jakarta.ws.rs:jakarta.ws.rs-api:4.0.0'
     // Implementation of the API
-    implementation 'org.glassfish.jersey.core:jersey-server:3.1.7'
+    implementation 'org.glassfish.jersey.core:jersey-server:3.1.8'
     // injection framework
     implementation 'org.glassfish.jersey.inject:jersey-hk2:3.1.8'
     implementation 'org.glassfish.hk2:hk2-api:3.1.1'
@@ -340,12 +340,12 @@ dependencies {
         exclude group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib-jdk8'
     }
     // GemxFX also (transitively) depends on kotlin
-    implementation 'org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.9.24'
+    implementation 'org.jetbrains.kotlin:kotlin-stdlib-jdk8:2.0.10'
 
     implementation 'commons-io:commons-io:2.16.1'
 
     testImplementation 'io.github.classgraph:classgraph:4.8.174'
-    testImplementation 'org.junit.jupiter:junit-jupiter:5.10.3'
+    testImplementation 'org.junit.jupiter:junit-jupiter:5.11.0'
     testImplementation 'org.junit.platform:junit-platform-launcher:1.10.3'
 
     testImplementation 'org.mockito:mockito-core:5.12.0'
@@ -362,7 +362,7 @@ dependencies {
     xjc group: 'org.glassfish.jaxb', name: 'jaxb-xjc', version: '3.0.2'
     xjc group: 'org.glassfish.jaxb', name: 'jaxb-runtime', version: '3.0.2'
 
-    rewrite(platform("org.openrewrite.recipe:rewrite-recipe-bom:2.16.0"))
+    rewrite(platform("org.openrewrite.recipe:rewrite-recipe-bom:2.17.0"))
     rewrite("org.openrewrite.recipe:rewrite-static-analysis")
     rewrite("org.openrewrite.recipe:rewrite-logging-frameworks")
     rewrite("org.openrewrite.recipe:rewrite-testing-frameworks")

docs/code-howtos/code-quality.md

@@ -8,8 +8,12 @@ parent: Code Howtos
 JabRef has three code style checkers in place:
 
 * [Checkstyle](https://checkstyle.sourceforge.io/) for basic checks, such as wrong import order.
-* [Gradle Modernizer Plugin](https://github.com/andygoossens/gradle-modernizer-plugin#gradle-modernizer-plugin) for Java library usage checks. It ensures that "modern" Java concepts are used (e.g., [one should use `Deque` instead of `Stack`](https://stackoverflow.com/a/73021741/873282)).
-* [OpenRewrite](https://docs.openrewrite.org/) for advanced rules. OpenRewrite can also automatically fix issues. JabRef's CI toolchain does NOT automatically rewrite the source code, but checks whether OpenRewrite would rewrite something. As developer, one can execute `./gradlew rewriteRun` to fix the issues.
+* [Gradle Modernizer Plugin](https://github.com/andygoossens/gradle-modernizer-plugin#gradle-modernizer-plugin) for Java library usage checks.
+  It ensures that "modern" Java concepts are used (e.g., [one should use `Deque` instead of `Stack`](https://stackoverflow.com/a/73021741/873282)).
+* [OpenRewrite](https://docs.openrewrite.org/) for advanced rules. OpenRewrite can also automatically fix issues.
+  JabRef's CI toolchain does NOT automatically rewrite the source code, but checks whether OpenRewrite would rewrite something.
+  As developer, one can execute `./gradlew rewriteRun` to fix the issues.
+  Note that [JabRef is available on the Moderne platform](https://app.moderne.io/organizations/JabRef/jabref?branch=main&origin=github.com), too.
 
 In case a check fails, [the CI](https://github.com/JabRef/jabref/blob/main/.github/workflows/tests.yml#L24C6-L24C6) automatically adds a comment on the pull request.
 

docs/code-howtos/faq.md

@@ -3,40 +3,73 @@ parent: Code Howtos
 ---
 # Frequently Asked Questions (FAQ)
 
-## Resolving common development errors
-
 Following is a list of common errors encountered by developers which lead to failing tests, with their common solutions:
 
-* Failing <b>Checkstyle</b> tests:
-  * <span style="color:green">Fix</span>: JabRef follows a pre-defined style of code for uniformity and maintainability that must be adhered to during development. To set up warnings and auto-fixes conforming to these style rules in your IDE, follow [Step 3](https://devdocs.jabref.org/getting-into-the-code/guidelines-for-setting-up-a-local-workspace/intellij-13-code-style.html) of the process to set up a local workspace in the documentation. Ideally, follow all the [set up rules](https://devdocs.jabref.org/getting-into-the-code/guidelines-for-setting-up-a-local-workspace/) in the documentation end-to-end to avoid typical set-up errors.<br> <b>Note</b>: The steps provided in the documentation are for IntelliJ, which is the preferred IDE for Java development. The `checkstyle.xml` is also available for VSCode, in the same directory as mentioned in the steps.
+## Failing tests
+
+### Failing <b>Checkstyle</b> tests
+
+JabRef follows a pre-defined style of code for uniformity and maintainability that must be adhered to during development. To set up warnings and auto-fixes conforming to these style rules in your IDE, follow [Step 3](https://devdocs.jabref.org/getting-into-the-code/guidelines-for-setting-up-a-local-workspace/intellij-13-code-style.html) of the process to set up a local workspace in the documentation. Ideally, follow all the [set up rules](https://devdocs.jabref.org/getting-into-the-code/guidelines-for-setting-up-a-local-workspace/) in the documentation end-to-end to avoid typical set-up errors.<br> <b>Note</b>: The steps provided in the documentation are for IntelliJ, which is the preferred IDE for Java development. The `checkstyle.xml` is also available for VSCode, in the same directory as mentioned in the steps.
+
+### Failing <b>OpenRewrite</b> tests
+
+Execute the Gradle task `rewriteRun` from the `rewrite` group of the Gradle Tool window in IntelliJ to apply the automated refactoring and pass the test:<br>
+![Executing Gradle task rewriteRun](../images/rewriteRun.png)
+
+Background: [OpenRewrite](https://docs.openrewrite.org/) is an automated refactoring ecosystem for source code.
+
+### `org.jabref.logic.l10n.LocalizationConsistencyTest findMissingLocalizationKeys` <span style="color:red">FAILED</span>
+
+You have probably used Strings that are visible on the UI (to the user) but not wrapped them using `Localization.lang(...)` and added them to the [localization properties file](https://github.com/JabRef/jabref/blob/main/src/main/resources/l10n/JabRef_en.properties).
+
+Read more about the background and format of localization in JabRef [here](https://devdocs.jabref.org/code-howtos/localization.html).
+
+### `org.jabref.logic.l10n.LocalizationConsistencyTest findObsoleteLocalizationKeys` <span style="color:red">FAILED</span>
+
+Navigate to the unused key-value pairs in the file and remove them.
+You can always click on the details of the failing test to pinpoint which keys are unused.
+
+Background: There are localization keys in the [localization properties file](https://github.com/JabRef/jabref/blob/main/src/main/resources/l10n/JabRef_en.properties) that are not used in the code, probably due to the removal of existing code.
+Read more about the background and format of localization in JabRef [here](https://devdocs.jabref.org/code-howtos/localization.html).
+
+### `org.jabref.logic.citationstyle.CitationStyle discoverCitationStyles` <span style="color:red">ERROR: Could not find any citation style. Tried with /ieee.csl.</span>
+
+Check the directory `src/main/resources/csl-styles`.
+If it is missing or empty, run `git submodule update`.
+Now, check inside if `ieee.csl` exists.
+If it does not, run `git reset --hard` **inside that directory**.
+
+### `java.lang.IllegalArgumentException`: Unable to load locale en-US <span style="color:red">ERROR: Could not generate BibEntry citation. The CSL engine could not create a preview for your item.</span>
+
+Check the directory `src/main/resources/csl-locales`.
+If it is missing or empty, run `git submodule update`.
+If still not fixed, run `git reset --hard` **inside that directory**.
+
+### `org.jabref.architecture.MainArchitectureTest restrictStandardStreams` <span style="color:red">FAILED</span>
+
+Check if you've used `System.out.println(...)` (the standard output stream) to log anything into the console.
+This is an architectural violation, as you should use the Logger instead for logging.
+More details on how to log can be found [here](https://devdocs.jabref.org/code-howtos/logging.html).
 
-* Failing <b>OpenRewrite</b> tests:
-  * <span style="color:green">Fix</span>: [OpenRewrite](https://docs.openrewrite.org/) is an automated refactoring ecosystem for source code. Execute the Gradle task `rewriteRun` from the `rewrite` group of the Gradle Tool window in IntelliJ to apply the automated refactoring and pass the test.<br>
-    ![Executing Gradle task rewriteRun](../images/rewriteRun.png)<br>
+### `org.jabref.architecture.MainArchitectureTest doNotUseLogicInModel` <span style="color:red">FAILED</span>
 
-* `org.jabref.logic.l10n.LocalizationConsistencyTest` `findMissingLocalizationKeys` <span style="color:red">FAILED</span>
-  * <span style="color:green">Fix</span>: You have probably used Strings that are visible on the UI (to the user) but not wrapped them using `Localization.lang(...)` and added them to the [localization properties file](https://github.com/JabRef/jabref/blob/main/src/main/resources/l10n/JabRef_en.properties).
-      Read more about the background and format of localization in JabRef [here](https://devdocs.jabref.org/code-howtos/localization.html).
+One common case when this test fails is when you put any class purely containing business logic inside the `model` package (i.e., inside the directory `org/jabref/model/`).
+To fix this, shift the class to a sub-package within the `logic` package (i.e., the directory`org/jabref/logic/`).
+An efficient way to do this is to use IntelliJ's built-in refactoring capabilities - right-click on the file, go to "Refactor" and use "Move Class".
+The import statement for all the classes using this class will be automatically adjusted according to the new location.<br>
+![Moving a file using refactor](../images/refactor-moving.png)<br>
 
-* `org.jabref.logic.l10n.LocalizationConsistencyTest` `findObsoleteLocalizationKeys` <span style="color:red">FAILED</span>
-  * <span style="color:green">Fix</span>: There are localization keys in the [localization properties file](https://github.com/JabRef/jabref/blob/main/src/main/resources/l10n/JabRef_en.properties) that are not used in the code, probably due to the removal of existing code. Navigate to the unused key-value pairs in the file and remove them. You can always click on the details of the failing test to pinpoint which keys are unused.
-    Read more about the background and format of localization in JabRef [here](https://devdocs.jabref.org/code-howtos/localization.html).
+More information on the architecture can be found at [../getting-into-the-code/high-level-documentation.md](High-level documentation).
 
-* `org.jabref.logic.citationstyle.CitationStyle` `discoverCitationStyles` <span style="color:red">ERROR: Could not find any citation style. Tried with /ieee.csl.</span>
-  * <span style="color:green">Fix</span>: Check the directory `src/main/resources/csl-styles`. If it is missing or empty, run `git submodule update`. Now, check inside if `ieee.csl` exists. If it does not, run `git reset --hard` <b>inside that directory</b>.
+## Gradle outpus
 
-* `java.lang.IllegalArgumentException`: Unable to load locale en-US<br> <span style="color:red">ERROR: Could not generate BibEntry citation. The CSL engine could not create a preview for your item.</span>
-  * <span style="color:green">Fix</span>: Check the directory `src/main/resources/csl-locales`. If it is missing or empty, run `git submodule update`. If still not fixed, run `git reset --hard` <b>inside that directory</b>.
+### `ANTLR Tool version 4.12.0 used for code generation does not match the current runtime version 4.13.1`
 
-* `org.jabref.architecture.MainArchitectureTest` `restrictStandardStreams` <span style="color:red">FAILED</span>
-  * <span style="color:green">Fix</span>: Check if you've used `System.out.println(...)` (the standard output stream) to log anything into the console. This is an architectural violation, as you should use the Logger instead for logging. More details on how to log can be found [here](https://devdocs.jabref.org/code-howtos/logging.html).
+Execute the Gradle task `clean` from the `build` group of the Gradle Tool Window in IntelliJ:<br>
+![Executing Gradle task clean](../images/clean.png)<br>
 
-* `org.jabref.architecture.MainArchitectureTest` `doNotUseLogicInModel` <span style="color:red">FAILED</span>
-  * <span style="color:green">Fix</span>: One common case when this test fails is when you put any class purely containing business logic inside the `model` package (i.e., inside the directory `org/jabref/model/`). To fix this, shift the class to a sub-package within the `logic` package (i.e., the directory`org/jabref/logic/`). An efficient way to do this is to use IntelliJ's built-in refactoring capabilities - right-click on the file, go to "Refactor" and use "Move Class". The import statement for all the classes using this class will be automatically adjusted according to the new location.<br>
-    ![Moving a file using refactor](../images/refactor-moving.png)<br>
+### `BstVMVisitor.java:157: error: package BstParser does not exist`
 
-* `ANTLR Tool version 4.12.0 used for code generation does not match the current runtime version 4.13.1`
-  * <span style="color:green">Fix</span>: Execute the Gradle task `clean` from the `build` group of the Gradle Tool Window in IntelliJ:<br>
-    ![Executing Gradle task clean](../images/clean.png)<br>
+Execute gradle task `clean` from the `build` group of the Gradle Tool Window in IntelliJ.
 
 <!-- markdownlint-disable-file MD033 -->

gradle/wrapper/gradle-wrapper.properties

@@ -1,7 +1,7 @@
 distributionBase=GRADLE_USER_HOME
 distributionPath=wrapper/dists
-distributionSha256Sum=d725d707bfabd4dfdc958c624003b3c80accc03f7037b5122c4b1d0ef15cecab
-distributionUrl=https\://services.gradle.org/distributions/gradle-8.9-bin.zip
+distributionSha256Sum=5b9c5eb3f9fc2c94abaea57d90bd78747ca117ddbbf96c859d3741181a12bf2a
+distributionUrl=https\://services.gradle.org/distributions/gradle-8.10-bin.zip
 networkTimeout=10000
 validateDistributionUrl=true
 zipStoreBase=GRADLE_USER_HOME