Skip to content

Conversation

@adaliszk
Copy link

Slight self-promotion, but added my Gradle plugin to handle Hytale modding, which gives the ability to:

  • Hytale server dependencies using the official Hytale Maven
  • Monorepo support through common "multiloader" and "library" patterns
  • Mixed Kotlin and Java projects with automatic dependencies
  • Automatic IDEA run configuration for JBR to hot swap
  • Hot-swapping code and resources, including live reloading

This should solve #6 nicely without mixing the contexts.

Copy link
Member

@ItsNeil17 ItsNeil17 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the PR - are there any direct advantages over this instead of gh-7?

Also could you please use the server from the maven instead now?

@adaliszk
Copy link
Author

adaliszk commented Jan 26, 2026

The plugin already uses the official Hytale Maven for the server.jar, as the features I described say. I have a fallback in my code to a launcher file that I intend to expose as a config option, but it is currently not used.

Differences between this and the other PR with the ultradev plugin:

  • Complete manifest schema exposed as typed properties instead of blossom-based manual casting.
  • Manifest is generated, not parsed from a template (but not specified values in gradle are retained), but full control is exposed via the Gradle config block, including ALL the fields that the server actually parses. Notably, the SubPlugins is also available to nest multiple configs.
  • Patchline and arguments for the server are not available, but will be added soon (actually working on a config update right now).
  • Using MavenLocal as first in the possible repos to allow local-overwrites to take over for those who test there first.
  • The plugin is published on MavenCentral over a custom external Maven.
  • Monorepo/Multiloader pattern is supported by using common {} block where you can do directories of common+hytale, or common/foo+common/bar+hytale, or even do multiple hytale projects
  • Kotlin support added via a simple useKotlin(), useKotlin("stdlib-dependency-name") or kotlin = "stdlib-dependency-name"
  • CurseForge Maven is pre-configured, meaning you can already depend on any mods on CurseForge, and publishing tasks are coming soon.
  • Hot reloading and swapping already pre-configured; the users only need to choose a DCEVM-ready JDK when running the automatically generated IDEA run configurations. Meaning you don't need to copy-paste a compiled jar, reboot, and anything like that; you get your changes applied in seconds.
  • Devserver is pre-configured with Creative and a Superflat, and already sets the auth store to be Encrypted so that a single login is needed, and the rest is already done.
  • The sources are directly linked in the server, so when you edit in the Asset Editor, the changes immediately show up in the source files, no extra steps.
  • VSCode run configuration is not generated, but as with all the others, it will come soon with Neovim support.
  • On clean, I am not deleting the devserver and all of its progress; that is up to the user, but I could make a cleanDevserver command to make it easier.
  • Testing frameworks are already pre-loaded and ready to be used. Examples will be posted in the plugin repo (and on the webpage) over time.

@adaliszk adaliszk changed the title feat: Implement #6 with a Gradle Plugin feat: Switch to Gradle using Plugin with both Java and Kotlin, and many more features Jan 26, 2026
Copy link
Member

@ItsNeil17 ItsNeil17 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - thank you very much!

@adaliszk
Copy link
Author

adaliszk commented Jan 26, 2026

Just quickly added a build script too for those who like to use that, the plugin works in both settings and build ;)
What does the issue-number check want to do?

@ItsNeil17
Copy link
Member

@adaliszk
Copy link
Author

No worries, I can make the changes ;)

@nicolube
Copy link

nicolube commented Jan 26, 2026

Is #7 Not needed anymore? This pretty much look like a replacement...

@ItsNeil17
Copy link
Member

Yeah I don't think its needed anymore.

@ItsNeil17
Copy link
Member

No worries, I can make the changes ;)

@adaliszk did you submit a PR?

@adaliszk
Copy link
Author

@adaliszk did you submit a PR?

@ItsNeil17 preparing it in the evening and will ping you soon

@WhaleFromMars
Copy link

WhaleFromMars commented Jan 27, 2026

Is it the best idea to be shipping such an opinionated gradle plugin in a template on the most widely known modding site? im all for ease of use, providing a way to run a server and generate sources is one thing, but everything else feels over the top, more like something that would ship with a framework that endorses it rather than a generic template. I feel like sticking as close to vanilla practices as possible while the ecosystem works itself out is the best bet.

On another note, I think you should be able to select a JetBrains Hot-Reload Capable JVM with https://github.com/gradle/foojay-toolchains for the user if im understanding correctly, might be worth looking into.

fwiw ive got a template generator akin to fabrics one in the works at my fork, I can put it up as a draft pr if you want

Switching to the ScaffoldIt Gradle Plugin adding:
- HytaleServer.jar via the official Hytale maven
- Monorepo support via `common {}` block
- Kotlin support via `useKotlin()` function
- Hot-reloading using DCEVM JVM and IDEA
- Automatic manifest in-place generation
- Automatic source path scaffolding
- Source-linked Devserver for zero jar
- Source-linked Asset Editor
@adaliszk
Copy link
Author

While the plugin pre-sets a lot of things and is prepared for multiple project templates, rather than writing less sophisticated plugins per setup type, I do not think it goes beyond vanilla, except for not anticipating a split-brain situation with both settings and build scripts both configuring the same thing, but from slightly different angles.

However, you can still write your long, 300-line, verbose vanilla scripts if you wish. If I'm missing any hooks you need, do tell me. I am happy to expose those, as my general goal is not to hide the configuration behind an opinion but to set sensible defaults, especially for those who are picking up Java for the first time. The upcoming changes will focus on configuration and on exposing every single toggle.

The only framework-related feature to me is the agent that ships the more complicated part of hot reloading that the simple DCEVM JVM is not capable of, namely, reloading your actual plugin even when you have dependencies. That is something none of the other plugins can do, as none of them goes beyond a run configuration. The only other alternative is installing a devtools mod that replaces the Hytale plugin manager with its own solution, which, while it may work, will be a burden to maintain and not cause any side effects.

@adaliszk
Copy link
Author

In any case, it is up to the maintainers. I was merely offering a zero boilerplate option that goes in the direction of Stonecutter and Blahaj from Minecraft modding.

Regarding the pages, I am working on them; from what I can see, they would remain mostly the same, though I am not sure about fully dropping the Maven sections, as they are undoubtedly very useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants