Migrate to javafx 27 and update fix gradle depcreation

[Siedlerchr]

Fixed migration issues and keep version at 0.3.0

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Migrate RichTextArea integration to JavaFX 27

✨ Enhancement ⚙️ Configuration changes 🧪 Tests 🕐 10-20 Minutes

AI Description

• Upgrade JavaFX dependencies and migrate RichTextArea usage to JavaFX 27 APIs.
• Mark the compatibility-breaking release by advancing the library version to 1.0.0.
• Adapt GUI and renderer tests to compile against updated incubator interfaces.

Diagram

graph TD
  B["Gradle Build"] --> J["JavaFX 27"] --> A["RichText APIs"]
  R["RichTextRenderer"] --> A
  T["Test Suites"] --> R
  T --> A

Loading

High-Level Assessment

Directly migrating to JavaFX 27 is appropriate because the changed incubator APIs require compile-time adaptations and the 1.0.0 version communicates the compatibility break. Remaining on JavaFX 26 would defeat the upgrade, while a reflection-based cross-version compatibility layer would add complexity around unstable incubator APIs without a demonstrated need.

Files changed (5) +15 / -9

Enhancement (1) +3 / -3

RichTextRenderer.javaAdapt link attributes and lookups to JavaFX 27 +3/-3

Adapt link attributes and lookups to JavaFX 27

• Creates the custom HREF attribute through the JavaFX 27 character-attribute factory. Updates RichTextArea and StyledTextModel attribute lookups to pass the new resolution flag.

src/main/java/org/jabref/htmltonode/rich/RichTextRenderer.java

Tests (3) +9 / -3

HtmlRichTextAreaTest.javaImplement the expanded JavaFX cell context contract +6/-0

Implement the expanded JavaFX cell context contract

• Adds the JavaFX 27 decorateRun method to the capturing CellContext test double. The no-op implementation preserves the test's focus on cursor styling.

src/test/java/org/jabref/htmltonode/HtmlRichTextAreaTest.java

RichTextAreaSpikeTest.javaMigrate RichTextArea spike coverage to JavaFX 27 APIs +2/-2

Migrate RichTextArea spike coverage to JavaFX 27 APIs

• Uses the character-style attribute factory and the expanded model attribute lookup signature. Existing GUI coverage continues validating custom link attributes and RichTextArea skin creation.

src/test/java/org/jabref/htmltonode/RichTextAreaSpikeTest.java

RichTextRendererTest.javaUpdate renderer attribute lookup helper for JavaFX 27 +1/-1

Update renderer attribute lookup helper for JavaFX 27

• Passes the new resolution flag when retrieving style attributes from rendered models, retaining existing headless renderer assertions.

src/test/java/org/jabref/htmltonode/RichTextRendererTest.java

Other (1) +3 / -3

build.gradle.ktsUpgrade JavaFX and advance the breaking-release version +3/-3

Upgrade JavaFX and advance the breaking-release version

• Bumps the project snapshot version from 0.3.0 to 1.0.0 and upgrades all JavaFX artifacts from 26.0.1 to 27. Rewrites the GUI test task registration using the typed Gradle API compatible with current dependency creation and task configuration.

build.gradle.kts

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Java 24 users get an unusable build ✓ Resolved 🐞 Bug ≡ Correctness

Description

javafxVersion moves compilation and tests to JavaFX 27, but options.release and the requirements
still advertise Java 24 and JavaFX 26 while the rich renderer uses the migrated API shape. Because
JavaFX is deliberately absent from publication metadata, consumers following those stated minimums
receive no dependency constraint that aligns their runtime with the version against which the
library is compiled.

Code

build.gradle.kts[32]

+val javafxVersion = "27"

Evidence

The build uses a Java 25 toolchain but still emits Java 24 bytecode based on an explicit JavaFX 26
compatibility comment, while the changed dependency baseline is JavaFX 27. The README tells
consumers that Java 24 and JavaFX 26 are supported and explains that JavaFX is omitted from the POM,
so consumers cannot rely on dependency metadata to correct the stale requirements.

build.gradle.kts[19-32]
build.gradle.kts[47-58]
README.md[14-24]
README.md[139-141]
README.md[175-178]
src/main/java/org/jabref/htmltonode/rich/RichTextRenderer.java[36-37]
src/main/java/org/jabref/htmltonode/rich/RichTextRenderer.java[97-102]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The build now compiles and tests against JavaFX 27 while still targeting and documenting the previous Java 24 and JavaFX 26 compatibility baseline. Since consumers must supply JavaFX themselves, the published requirements must match the migrated implementation.
## Fix Focus Areas
- build.gradle.kts[25-32]
- README.md[14-24]
- README.md[137-141]
- README.md[175-178]
## Recommended Fix
Set the bytecode release and comments to the Java version required by JavaFX 27, update the documented minimum to JavaFX 27 and its corresponding Java runtime, and change the RichTextArea documentation link to version 27. If Java 24 and JavaFX 26 must remain supported instead, avoid APIs unavailable on that baseline and compile and test against JavaFX 26.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Local installs request a missing version ✓ Resolved 🐞 Bug ≡ Correctness

Description

The project version now publishes locally as 1.0.0-SNAPSHOT, while the local-development
dependency example still requests 0.3.0-SNAPSHOT. Developers following publishToMavenLocal and
then copying that example cannot resolve the artifact produced by the current build.

Code

build.gradle.kts[13]

+version = "1.0.0" + (findProperty("versionSuffix")?.let { "-$it" } ?: "") + "-SNAPSHOT"

Evidence

The changed build version is used directly by the published Maven coordinates, and the README first
instructs developers to run publishToMavenLocal before requesting a different version. Those two
commands therefore produce and consume different coordinates.

build.gradle.kts[10-13]
build.gradle.kts[87-90]
README.md[47-61]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The version bump changes the locally published snapshot coordinates, but the README still instructs consumers to depend on the previous snapshot version. The installation example must reference the artifact generated by the current build.
## Fix Focus Areas
- build.gradle.kts[10-13]
- README.md[47-63]
## Recommended Fix
Change the local-development dependency example to `org.jabref:html-to-node:1.0.0-SNAPSHOT` and update the nearby version-suffix comment in the build script so its example uses the current base version.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[koppor]

Also adapt changelog? 😅

I am not sure if we are ready for 1.0.0, but we can always start 2.0.0 😅

[Siedlerchr]

I changed back to 0.4.0 and added a new entry to changelog unrelaesed

[koppor]

Before 1.0.0 one can do whatever one wants.

[koppor]

We do 0.3.0 - 1.0 for JabRef 6.0

[Siedlerchr]

Sorry I don't get what you want?

[Siedlerchr]

Should I change the version in changelog here or separate?

[Siedlerchr]

I changed it back to 0.3.0