Improve build system

[Nuckerr]

Changes so far:

Convert build files to kotlin

I did this because gradle is making kotlin the default for build files . Also, it is far easier to work in than groovy, and anyone working on the codebase should be familiar with kotlin, so having the build files in kotlin only makes sense.

Add run-paper task

I added the run-task plugin which adds a paper > runServer task. This will create a folder called run, download and run the last build of 1.19.4 paper, and build and load the plugin into that server. This means you can now create an intellij configuration easily, and run the server using intetllij's debug features (including hot-swap (sometimes), as well as making life just easier.

Other changes

• I added this new run folder to the gitignore, so it wont be on github, just locally.
• I added the entire idea folder to the gitignore (it was annoying me). But it willl except the .idea/name which is already in the codebase.
• I removed kotlin testing, it didn't seem like it was being used at all.

Changes todo

Integrated hangar publishing

Using the hangar-publish-plugin (and probably a range of github actions) to automate parts of the release to hangar.

Other things

• Update all the plugins
• Update al the dependencies
• Remove application plugn? (doesnt seem to be used, is it intended to be in there)

Is the spigot dependency meant to be on 1.16.4?

[Nuckerr]

Understanding the hangar release system

There are two tasks:

• publishReleasePublicationToHangar
• publishNightlyPublicationToHangar

A release is either a pre-release or an actual release. To make it a pre release, make sure the version ends in -SNAPSHOT (perhaps we might want to rename either the channel or the ending to make this consistent, idk, up to you)

It is also important that before we run this task, that we make sure that the git hash in the gradle.properties is the first commit since the previous release (so for example ours is going to be d3e5fff5ccfb54f1b055290d907f6f82d501dcaf. This is used for generating the changelog

A nightly released is designed to be run after every commit for the bleeding edge. It's version will be the hash of that commit, with the changelog just being the commit's message.

The other thing, is we wont run these tasks manually. My next pr is to make some github actions that automate this entirely, eg:

• An action that will run the release task when a github release is posted
• An action that will run the nightly task every commit pushed to master

Example of the release changelog: (with prerelease)

Example of nightly changelog:

[Nuckerr]

Me and @sttephen will need to sort out how the actions run on the repository, as well as how the hangar resource is set up. Please DM on discord