Build modernization: Kotlin DSL, Gradle 9.6.1, Java 25, Vineflower tuning

[sequwi]

Summary

This PR modernises the NeoForm build system across five logical commits:

1. Migrate build scripts to Kotlin DSL with version catalogs

• settings.gradle → settings.gradle.kts (Kotlin DSL)
• plugin/build.gradle → plugin/build.gradle.kts (Kotlin DSL)
• Root version catalog: gradle/libs.versions.toml
• Plugin version catalog: plugin/gradle/libs.versions.toml

2. Update Gradle wrapper to 9.6.1 with SHA-256 verification

• Upgrade from 8.x → 9.6.1
• distributionSha256Sum set for integrity verification
• -all distribution retained for IDE source navigation

3. Update CI workflows for JDK 25 and cache optimisation

• Bump JDK 21 → 25 in all workflows
• Add gradle-home-cache-cleanup for disk space management
• Enable cache-read-only for PRs and ephemeral runners

4. Tune gradle.properties for performance

• Daemon idle timeout: 3 min → 1 hour
• Enable file system watching (vfs.watch=true)
• Enable parallel tooling API
• JVM heap: 2 GB → 4 GB (decompiler requirement)
• JVM file encoding set to UTF-8
• Config cache ignore paths for volatile CI directories

5. Migrate task classes to Gradle 9.x API and fix minor issues

• Replace all @DisableCachingByDefault with @UntrackedTask(because = "...") (removed in Gradle 9.x)
• Add @PathSensitive on all @InputFile/@InputDirectory properties (required by validatePlugins with enableStricterValidation = true)
• Add DiffPatch .context(10) for more robust patches
• Fix CreatePatchWorkspace import conflict (diffpatch Input vs Gradle Input)
• Fix HTML entity in NeoFormExtension (& → &)
• Reproducible ZIP outputs for createDataArchive

Testing

• :plugin:build passes with validatePlugins { enableStricterValidation = true }
• Full :check requires network access and ~4 GB heap (decompiler pipeline) — not run locally

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

[sequwi]

I was unable to run the full :check pipeline locally due to resource constraints (decompiler requires ~4 GB heap). If someone with a suitable environment could trigger the full check in CI, I would appreciate it confirming everything works end-to-end.

All 5 commits build successfully with :plugin:build and pass validatePlugins.enableStricterValidation = true.

Ready for review.

[embeddedt]

Can you explain what motivates this change?

[sequwi]

Can you explain what motivates this change?

Honestly, in my opinion the project was running on outdated tooling, so I decided to go through and update everything across the board: newer Gradle, newer Java, Kotlin DSL for better maintainability, plus some decompiler tuning to improve output quality. Partly wanted to contribute something meaningful to the project, and partly just wanted to modernize it for its own sake.

[embeddedt]

The reason I ask is that this PR appears to be largely unmodified output from an LLM-based agent (with all the usual issues, such as the diff being complex for what it does, lack of rationale/explanation for many parts, no human-written PR description, etc). While we don't have a strict "no LLM" policy, contributions in this state are much less likely to be merged.

[sequwi]

The reason I ask is that this PR appears to be largely unmodified output from an LLM-based agent (with all the usual issues, such as the diff being complex for what it does, lack of rationale/explanation for many parts, no human-written PR description, etc). While we don't have a strict "no LLM" policy, contributions in this state are much less likely to be merged.

That's fair, you're right that I used AI assistance for this. I don't write code myself, so I relied on AI tools to put this together. Understand if that makes it harder to merge as-is, but figured something is better than nothing. Let me know if there's anything specific that's a blocker and I can look into it.

[shartte]

I don't write code myself, so I relied on AI tools to put this together.

Sorry, not interested in spending time to review this.

[embeddedt]

Understand if that makes it harder to merge as-is, but figured something is better than nothing.

Unfortunately no. I am aware the current marketing around these tools is extremely misleading and you probably mean well. However, current LLM tooling does not produce maintainable code unless prompted carefully with an appropriately sized task, and that judgement requires programming experience. Maybe things will be different in a couple years, but as it stands, for large changes like this LLMs only save time if being prompted by someone who already has a rough idea of what the output should look like, and can therefore spot maintainability issues immediately. There is also at least a little bit of educational benefit when used that way, as the operator can follow along and mostly understands what is being done, and may learn some new tricks they can apply to their own manual programming (yes, that's still relevant!).

By contrast, in our current scenario here, it's a waste of time for everyone involved here to play telephone with your agent via review comments, due to how slow the feedback loop would be and the limited educational value to you (as a non-programmer).

TL;DR today's LLMs are not a substitute for effort and experience; they merely multiply what can be done with existing effort and experience on some narrow domains.