Update build process to gradle

[Joo200]

Why? Because with gradle you can use the paperweight userdev plugin. With that plugin you don't need to deploy the source code from the server to maven local (and don't need to install maven to compile your plugin).

I tested the plugin on 1.19.2 and it still works.

But there are some ToDos:

• [ ] Modify the scripts in the scripts folder. I don't know exactly what they do.
• [ ] Change the CI workflow to use gradle
• [ ] Validate everything on 1.18.2 (I don't see a reason why it shouldn't work there)

[Jikoo]

I've been thinking about Gradle to introduce more generic update support by rewriting a small amount of bytecode with ASM during compilation without having to write and publish an entire Maven plugin. That said, there is absolutely no way I'd swap to Gradle with scripts not updated. I do not compile release builds myself. Every build that has been released since like 4.1.0 or something has been compiled and attached to a draft by Actions. I review the changelog included, I usually manually pretty it up a little, and then I push the release button. I also don't even manually upload to Bukkit any more, again because of Actions. Breaking the pipeline for something I don't need is a huge increase in the annoying and boring part of the workload for no real benefit.

On a personal level, the counter to this (and Gradle in general) being good is "If installing Maven is a problem, you can create your own fork of this repo and enable Actions runs on it. Then you don't even need a computer to compile, all you have to do is be able to use GitHub's web client to commit new code." OI is fully set to build itself for you, all you need to do is make your changes.

[Jikoo]

As far as what scripts do, the names are pretty descriptive and they're commented pretty thoroughly. The only one I would expect to majorly change would be get_spigot_versions, because there is no more Maven structure to parse. I assume Gradle has similar functionality to the Maven help plugin, but I am not particularly familiar with it.

[Joo200]

you can create your own fork of this repo

TBH: that's the whole point of the PR. I want to fork that project as I have to adjust some stuff to my own server implementation. However this fork will not be on github and will be build in gitlab ci.

If you want to stick around with your build setup, that's fine for me. I made those adjustments because it's much easier to develop with the paperweight userdev plugin from paper instead of installing the Spigot BuildTools and compiling every version myself. But as I already made those build step changes I thought it would be handy for you to update to gradle.

Feel free to reopen/use my stuff when needed but I don't have the time to fully understand your build and publish pipeline.

[Jikoo]

I want to fork that project as I have to adjust some stuff to my own server implementation. However this fork will not be on github and will be build in gitlab ci.

I know you've already put in the work to set up your fork how you like, but GitLab CI is very similar to Actions. Adapting OI's build process should be pretty simple if a basic automatic runnable state is all you want. Just use an image with Maven, Java, and Bash, run the install_spigot_dependencies script (your directory when running it should be the project root directory, not sure where GitLab puts you by default), and compile with Maven.

I made those adjustments because it's much easier to develop with the paperweight userdev plugin from paper instead of installing the Spigot BuildTools and compiling every version myself. But as I already made those build step changes I thought it would be handy for you to update to gradle.

That's a good point. Frankly I kind of assume everyone already has recent NMS revisions installed locally from various other plugins. Kinda shocked that people work with NMS and don't. Locally I use a script that hasn't needed changes beyond adding the mojang-mapped flag since the release of BuildTools - a new NMS revision is just an excuse to make a coffee, as is pretty much any compilation process that involves installing Mojang code no matter what tool is involved. I also don't clear my local Maven repo often, so I still have some pretty ancient NMS versions preinstalled. These Gradle-based tools actually tend to be slower overall locally for me due to that extra step, though repeated builds are definitely faster.

Feel free to reopen/use my stuff when needed but I don't have the time to fully understand your build and publish pipeline.

I think we're at opposite ends of the same boat here. Gradle is probably worth it, but moving to it will break the process that makes my life very easy, and my understanding of Gradle is pretty basic. Because of the work involved (which I'm not sure will actually benefit me locally) I have low motivation to figure out how to get the information I need out of Gradle to update the scripts to a new process.