Chojo - Dev Blog and Portfolio

Let's Craft Code - Eine Buchrezension

chojo — Sun, 21 Dec 2025 20:49:24 +0100

Let's Craft Code - Eine Buchrezension

Note

Sorry guys and gals. That's a review for a german book, so no english here.

Keine Sorge, dieser Blog bleibt weiterhin technisch und wird nicht zum Buchblog, aber diesem Buch würde ich hier gern etwas Aufmerksamkeit widmen.

Oh nein, noch ein Buch, das Programmieren beibringt. Das ist bestimmt wieder super trocken und ich verliere die Motivation.

Wenn du das denkst, könnte dieses Buch jedoch genau das richtige sein.

Wenn das nicht das erste Mal auf meinem Blog ist, weißt du, wer ich bin.Ich bin Nora und dieses Buch kenne ich vermutlich fast genauso gut, wie der Author selbst. Denn ich habe dieses Buch auf technische Fehler geprüft, während es geschrieben wurde.Gemeinsam mit dem Author Max oder auch BiVieh (oder Schloool) haben wir dafür gesorgt, dass sich in den Beispielen und Aufgaben im Buch keine Fehler eingeschlichen haben.Vor allem haben wir darauf geachtet, dass du mitkommst, die Beispiele nicht zu schwer sind und du Stück für Stück an das Programmieren herangeführt wirst.

Es mag jetzt natürlich super biased sein, wenn jemand, der am Buch selbst mitgearbeitet hat, eine Rezension schreibt, aber wer, wenn nicht ich, hat vermutlich den besten Block von außen?

Max ist es gelungen, mit dem Buch "Let's Craft Code" ein Buch zu schreiben, dass ich wirklich guten Gewissens auch Anfängern and Herz legen kann.Mein größtes Problem mit Programmierbüchern ist nahezu immer die endlose Erklärung mit Beispielen, bei denen ich zwar am Ende einen Haufen Code habe, aber wirklich etwas sehen tue ich nicht abgesehen von einer Konsolenausgabe.

Mit Minecraft hat hier Max vermutlich wirklich die beste Platform gefunden den geschriebenen Code sichtbar zu machen. Wir können ihn zwar immer noch nicht anfassen, aber sehen funktioniert wirklich wunderbar.

Nun aber mal zu dem Inhalt selbst. Java erschlägt einen super gerne mit vielen Dingen. Es ist nun mal eine komplexe Sprache, die einfach grenzenlose Möglichkeiten eröffnet.Max hat es hier aber geschafft, eine wirklich sinnvolle Reihenfolge zu finden und die Konzepte anschaulich an praktischen Beispielen zu demonstrieren. Natürlich wird von Anfang an nicht alles erklärt. Aber genau das hält die Komplexität erstmal gering und wir können uns auf kleinere Abschnitte konzentrieren, die wir verändern und anpassen für das, was wir erreichen wollen.Stück für Stück kommt so mehr Sinn in unseren Code und wir verstehen immer mehr der Bezeichnungen, die wir bisher lediglich verwendet haben, ohne sie zu verstehen.Zur besseren Verinnerlichung gibt es nicht nur zu jedem Konzept ein Code Beispiel, sondern auch Praxisbeispiele und zwei Große Parts mit komplexeren Beispielen, die schon fast vollständig funktionale Plugins darstellen.Den ganzen Code musst du natürlich auch nicht abtippen. Alles ist in einem GitHub Repo verfügbar. Solltest du doch einmal feststecken, kannst du dich jederzeit in Discord melden.

Ziel des Buches ist es aber natürlich nicht, aus dir einen professionellen Entwickler zu machen, der morgen bereits anfangen kann zu arbeiten. Es ersetzt natürlich auch kein Studium. Auch wird es dir nicht alle Funktionen erklären, die Java zu bieten hat.Aber das ist auch gar nicht das Ziel des Buches. Es gibt dir die Werkzeuge in die Hand, dich selbst weiterzuentwickeln. Es führt dich in eine Welt ein, die so grenzenlos ist wie die Welt von Minecraft.

Um mal einen Vergleich zu haben: "Let's Craft Code" umfasst etwas mehr als 400 Seiten. Super viele praktische Beispiele und detaillierte Erklärungen. "Java ist auch eine Insel" ein wirklich sehr gutes Fachbuch für Java, das wirklich nahezu alle Funktionen von Java abdeckt, hat 1200 Seiten. Hier wurde vor allem gut und sinnvoll gekürzt, um viel Platz für praktische Beispiele zu schaffen.

Am Ende bist du auf jeden Fall in der Lage eigene Plugins zu entwickeln. Und vor allem verstehst du jetzt alle wichtigen Grundkonzepte von Java und kannst dich basierend auf diesen weiterentwickeln und dein Wissen erweitern.Und wer weiß, mit etwas Glück schenkt uns BiVieh noch einen weiteren Teil, in dem Bereiche, die es leider nicht in dieses Buch geschafft haben, auch noch Erwähnung finden.

Ich freue mich auf jeden Fall, dass wir endlich ein Buch haben, dass ich wirklich guten Gewissens anderen Menschen empfehlen kann, die Minecraft lieben und Programmieren lernen wollen.

Neugierig geworden? Das Buch ist im Rheinwerk verlag erschienen und in nahezu jedem Buchladen erhältlich und natürlich auch als E-Book.Die physische Printversion ist aber auch schön anzusehen.

Weitere Infos gibts hier

Gradle Basics

chojo — Mon, 26 Aug 2024 19:17:15 +0200

Gradle Basics

This blog post is about the basics of gradle. It is part of a longer series focusing on different build approaches using gradle. I will link further in depth posts for specific topics at the end of the post. During the Blog post I will show a lot of snippets. Those snippets will be mostly shorted and previously added stuff will not be shown. You will find spoilers sometimes that include the full files. Check those if you get lost on how your build file should look like.

This blogpost will mainly cover the general structure of gradle files, more precisely the gradle.build and gradle.settings files.

What is Gradle

Before we start with using Gradle, we should clear up what Gradle is.

Gradle is a so-called project management system. Some refer to is as build tool as well.Both are technical right. Gradle manages your project by allowing you to define your dependencies. In the end gradle will build your project depending on your build definition.

To manage your project gradle uses a so-called domain specific language or DSL in short form.This language can be currently Groovy or Kotlin. While Groovy is older, Kotlin gains more and more popularity as a DSL and is considered the way to go today. You can see that you are using Kotlin as your DSL if your gradle.build file ends with .kts. The same goes for your gradle.settings file. So if your files are named gradle.build.kts and gradle.settings.kts you are on the right track.

It is also important that the DSL has nothing to do with the language you use for your project. You can use Kotlin as your DSL and still write your programm with Java or any other supported language

Since gradle uses a DLS to define your build logic, you are much more flexible compared to Maven. Where you would need a ton of xml or plugins in Maven, Gradle usually just needs a couple of Kotlin or Groovy code.

The general approach of gradle is that we use plugins to allow certain actions, which are named tasks. Those tasks usually depend on each other and are executed in a predefined order. We as the user can usually configure the plugin itself and the tasks, that the plugin added. We can also define own tasks, that for example depend on some other task or that are run as a standalone task.

But that's enough for now. Time to actually set up our gradle project.

Install Gradle

If you are using Intellij, you actually don't need to worry about this step.Gradle is already bundled in IntelliJ, and you don't need to install it. You will simply use the wrapper, which will be explained in the next section.

If you are using other IDEs I strongly suggest switching to intellij. Most projects will have a gradle wrapper in it, so installing gradle locally isn't usually necessary anymore, unless you don't use IntelliJ and want to set up a new Project.

So if you for any reason need to install Gradle, you should refer to their official documentation or install with the package manager of your choice.

The Gradle Wrapper

The Gradle wrapper is essentially a portable Gradle installation.It does not require a Gradle installation on the system and can be used to build anywhere.Gradle releases frequent updates and the wrapper should ideally be updated to the latest version. To update this version you only need one command:

./gradlew wrapper --gradle-version=9.5.1 --distribution-type=bin

This works on Unix systems as well as in Windows PowerShell or git bash.If you are using windows cmd, you will need to use gradlew.bat instead.

Check the Gradle website for the latest version.

If you have a gradle project that lacks a wrapper, the command above will create it for you. But for that you will need to have some gradle version installed on your system and use gradle instead of ./gradlew at the start of the command.

Setting up a Gradle Project

Using IntelliJUsing EclipseUsing CLI

We will look at the marks one after another. Most of the settings will be set by default already.

We select New Project
We add our project id aka name.
This name is your plugin name in lower case with - where a space would be.
So MyPlugin becomes my-plugin
Make sure that a git repository will be created
Select Java as language or Kotlin if you like this more, but I will only use Java here.
Select Gradle as build system
Select Kotlin as Gradle DSL
Let intellij add some sample code.
This will be removed later, but will create the most important directories.
Select the wrapper as your Gradle distribution
Enter the latest Gradle version, as mentioned on the Gradle website.
This may not be available to select in the drop down menu, but you can enter it yourself.
Enter your group id here.If you don't know what to write here have a log at my other postIf you don't have a domain, see here
This is the same as your name in 2.

Sorry Eclipse users.Time to use an actually good IDE.Switch to IntelliJ c:

If you already have a project, you can easily set it up from the command line.If your project is currently a Maven project, Gradle will offer to convert it to a Gradle project.

We will look at how to set up a new Gradle project without importing anything from Maven.

First we start by initialising Gradle with Gradle init.We're using the installed version of Gradle for this, so you need to have it installed.

You will end up with this dialogue

Select type of project to generate: 1: basic 2: application 3: library 4: Gradle pluginEnter selection (default: basic) [1..4]

Choose 1 here by simply typing 1, or just hit enter since basic is the default.This will create a basic Gradle project.

If you want to create a library instead, you can choose 3.However, all this does is to apply some basic plugins beforehand, which we will get through later anyway.

The next step is to select the language for our Gradle DSL

Select build script DSL: 1: Kotlin 2: GroovyEnter selection (default: Kotlin) [1..2]

Again, choose 1 by typing 1 or just hit enter since Kotlin is the default.

Now we need to enter our project name.I recommend using your plugin name in lower case and adding - where there would be spaces.So MyPlugin becomes my-plugin.

Project name (default: directory):

Next is a question about Gradle stuff.

Generate build using new APIs and behavior (some features may change in the next minor release)? (default: no) [yes, no]

I recommend using the default no. So just press enter or type no.And you're done.

Gradle files

Now you have a bunch of new files and directories.Let's go through them one by one.

.gradle

The .gradle directory contains internal gradle data.It should be added to your gitignore if not done already.

gradle directory

The gradle directory contains the wrapper directory, which in turn contains a gradle-wrapper.jar, which is your Gradle wrapper.This is your portable Gradle installation as mentioned earlier.

The gradle-wrapper.properties contains the settings of the wrapper.The most important part is the version.You can also change it here if you forgot to use the command shown in the previous section.

This directly should always be pushed to git

gradlew and gradlew.bat

These are the Gradle wrapper files. You use them to execute your gradle wrapper.

gradlew for Unix systems, Windows powershell and git bash on Windows.
gradlew.bat for the windows cmd

build.gradle.kts

The build.gradle.kts is the heart of our project.Almost all the configuration of our project is done in this file.It contains dependencies, repositories and lots of other stuff.We will go over the sections in here in depth,

settings.gradle.kts

The settings.gradle.kts can be used to apply project wide settings such as plugin repositories (not dependency repositories!).You can also define submodules here if you have a multi-module project, or create a version catalogue.Currently, it only holds our project name.

src directory

While this directory is not strictly seen as part of Gradle, it is still important to have a specific structure:

.└── src/ ├── main/ │ ├── java │ └── resources └── test/ ├── java └── resources

If these directories do not exist in your src directory, please create them.

If you are creating a Kotlin project instead of a Java project the java directory will be named kotlin instead.

the src/main directory contains your programm logic and resources which will be compiled and moved into your jar in the end.

The src/test directory is for unit testing.

The basic build.gradle.kts

Let's start by taking a look at our build.gradle.kts.It should be empty at the moment if you used the cli approach, or already have some stuff in it if you set it up using IntelliJ.

Let's get you on the same page by adding some sections to start with a fresh file.

The plugin section

The top section of our file will always be the plugins section.So we start by adding it first.

plugins {}

The whole logic of Gradle is that plugins add tasks that we execute.Since we want to build a Java application, we need to add the java plugin.This can be done by simply adding java to the plugins block.

plugins { java}

And that's it. We are done with our plugin setup for now.

While we have added the java plugin now to our project, it lacks the configuration. Usually plugins have some kind of general configuration block, beside the tasks they add.

Plugin import syntax

We imported the java plugin with the short import syntax.This can be done with every plugin that is bundled with gradle already.If our plugin name is not only consisting of letters we need to quote our plugin with backticks. The maven-publish plugin would be imported like this:

plugins { `maven-publish`}

The normal syntax for importing a bundled plugin would be actually like this:

plugins { id("java")}

If you need to import a plugin that is not bundled in gradle you need to also supply a version. In that case all you need to do is to define the version of the plugin after the id.

plugins { id("com.gradleup.shadow") version "9.4.1"}

Checkpoint

plugins { java}

Declare group and version

Now we need to declare our group and version.This is not a section, just two values we assign.Your group id, if not already set, should be a domain you own in reverse order.If you don't have a domain, see my other post.I recommend using semantic versioning (semver) for your version.

group = "dev.chojo" // Please use your own group id c:version = "1.0.0-SNAPSHOT"

Checkpoint

plugins { java}group = "dev.chojo" // Please use your own group id c:version = "1.0.0-SNAPSHOT"

Repositories section

The repositories section is where we define which repositories our dependencies will be in.

The repository section looks like this:

repositories {}

Note

Order is important!

The order in which you assign repositories in this section is the order in which Gradle will search for dependencies.It will take the first found location where the dependency exists.

To add a repository, we can use two different ways.

Predefined Repositories

Gradle provides convenience functions to import common repositories

mavenCentral()
This is the Maven Central repository where most of the dependencies we will need are located. If you have been using Maven: With Maven you did not need to import this specifically, but with Gradle you will need to do so.
mavenLocal() This imports your local maven repository. This should usually not be used on public sources since it breaks the assumption that a project can be build everywhere.

Custom repositories

If a dependency happens to not be located in the Maven Central repository or your local Maven repository, we need to import a custom repository. You can easily do that with the maven() function.

repositories { maven("https://repo.papermc.io/repository/maven-public/")}

This will import the paper-mc repository. Of course, you can do the same with any other repository.

Checkpoint

plugins { java}group = "dev.chojo" // Please use your own group id c:version = "1.0.0-SNAPSHOT"repositories { mavenCentral()}

Dependencies section

Note

If you have test imports from junit here, you can delete them for now.

Inside the dependencies section, we can define two different dependency types for now:

dependencies { compileOnly("io.papermc.paper:paper-api:26.1.2.build.63-stable") implementation("de.chojo.sadu", "sadu", "2.3.9")}

Note

SADU is here only for demonstration purposes and not mandatory required

I have used two different ways of declaring dependencies here.Both are valid.You can either declare them as one string or as three separate strings.

SADU is a library I wrote to make using databases easier for beginners. Have a look at it c:

When we run our application we rely on the classes we are using to be there. In java there are multiple ways to make those classes of our dependency available.In this step we don't care yet how those classes will be made available. At this point we only care about who is responsible that the classes will be there.

As implementationAs compileOnly

If we are responsible for the classes to be there, we use implementation. This is for example the case when we write a Minecraft plugin for a paper server and we want to use a library that is not included in paper.

The compileOnly import means that the classes we are depending on will be there and that we are not responsible to ensure that they are there.If we stay in the Minecraft context, that means that every other plugin like FAWE, LuckPerms and in general any other api by other plugins or the server itself will be imported as compileOnly.APIs that are not available as plugins on the server, which can be the case for Inventory APIs for example, must of course be imported as an implementation.

Note

There are other types of import like runtimeOnly, but those two are the most important for now.

Tasks section

Note

You can delete anything currently in your tasks section

I told you earlier that everything in Gradle works with tasks.So there has to be a way to configure them, and this is where the tasks section comes in.For now, we will just start with a simple empty section.In the next section you will see how we configure a task of the java plugin.

tasks {}

Configuring Java

Now that we have all the necessary sections in our file, we can finally start configuring our project.

As told previously plugins provide tasks and usually some own configuration for the plugin itself.Currently, the only plugin we have imported is java, so we need to configure it.As we have a dependency, repositories and tasks sections, plugins can add own sections to our build file. Those sections are also called extension.Those are not added automatically, but we can easily access them by writing the plugin name and opening a code block.

java {}

Note

That the plugin configuration can be opened with the plugin name is a best practice.While most plugins adhere to this, it is not always the case.Consult the documentation of the plugin if you are unsure.

This will give us access to the configuration of our java plugin.

java { toolchain { languageVersion = JavaLanguageVersion.of(21) } withSourcesJar() withJavadocJar()}

For java we set the so-called toolchain.The toolchain controls the version of java used in our project.If you want to import a dependency compiled with java 21, you need to set your toolchain to 21 as well.On the other hand, using a java 21 toolchain will still allow you to import any dependency using an older version of java.

We also define that we want to build a source jar and a javadoc jar.This may not be important to us now, but it may be in the future.It doesn't hurt to have it in the end.

Note

When you create a javadoc jar, you get a warning for every missing comment on classes and methods. If you don't work on a public library or plugin you can ignore them or remove the withJavadocJar() call. If you work on a public library, I highly recommend to comment your code instead

In addition to configuring our java plugin, we also want to configure its tasks.There are three tasks of interest to us:

compileJavacompileJavaTestjavadoc

This task is responsible for compiling our Java code.

This task handles the compilation of our test code written in Java.Although we do not have any tests yet, it cannot hurt to define them anyway.

This handles how our javadocs are built.

All we want to define for these tasks is that we want to use UTF-8 encoding for them.This will avoid weird characters when using special characters.

tasks { compileJava { options.encoding = "UTF-8" } compileTestJava { options.encoding = "UTF-8" } javadoc { options.encoding = "UTF-8" }}

Note

On newer versions, the use of UTF-8 is the default.I keep it here because its a good example for easy task configuration.

And that's the configuration for our Java plugin.

Checkpoint

plugins { java}group = "dev.chojo" // Please use your own group id c:version = "1.0.0-SNAPSHOT"repositories { mavenCentral() // External repository maven("https://repo.papermc.io/repository/maven-public/")}dependencies { // We are not responsible to provide the classes from this dependency compileOnly("io.papermc.paper:paper-api:1.21.1-R0.1-SNAPSHOT") // We are responsible for providing the classes from this dependency implementation("de.chojo.sadu", "sadu", "2.2.5")}java { toolchain { languageVersion = JavaLanguageVersion.of(21) } withSourcesJar() withJavadocJar()}tasks { compileJava { options.encoding = "UTF-8" } compileTestJava { options.encoding = "UTF-8" } javadoc { options.encoding = "UTF-8" }}

Building the plugin

There is nothing stopping us from building our application now.While we could stop here and just be happy that it works, there is still a lot (and by that I mean A LOT) of room for improvement.We also still have to fix the problem of not including our library that we previously imported with implementation.So while you might be tempted to call it a day, I highly recommend you keep reading!

For now, I will just show you the two ways to run a Gradle task.

Note

You can run not only the build task with this, but any other task as well.If you are using IntelliJ you can have a look at the other tasks that are available.

Via cliVia IntelliJ

Go into your cli and run ./gradlew build' orgradlew.bat build' depending on your operating system.

Open the Gradle window on the right. Go to Tasks -> Build and run the build task by clicking on it.

Getting the build file

You will now find your application in build/libs/myproject.jar.

Thank you for sticking with me so far.You now have a very good understanding of the structure of a gradle file.Its time now to choose your path c:

Thanks for reading!If you liked this post, or have some questions, feel free to come by my discord and have a chat!

Or write me a mail at mail [at] chojo [dot] dev.

If you want to support me, feel free to sponsor me via GitHub.

Gradle Application Plugin

chojo — Mon, 26 Aug 2024 19:17:15 +0200

Gradle Application Plugin

The application plugin is included in Gradle and is a nice alternative to shadow when your application is standalone.For example a webservice or Discord bot.It is however not useful, when your application is a minecraft plugin.Please see the minecraft post for that.

For this post I will assume that you have the build files we ended up with in the previous post.

What is the application plugin

The application plugin is bundled in gradle and one of the easiest way to ship your application.It creates a zip and tar archive that contains the jar of all our external dependencies and our own jar.It also creates a start script for our application, that we can execute to start our application.

Apply the application plugin

To apply the application plugin we add it into our plugins section

plugins { java application}

All that is left now is some minimal configuration or the application plugin, which at least requires to define the main class.For simplicity my main class is located at dev.chojo.myapp.Main.

application { mainClass = "de.chojo.myapp.Main"}

Additionally, we can also provide some default JVM arguments for our app.

application { mainClass = "de.chojo.myapp.Main" applicationDefaultJvmArgs = listOf("-Dapp.language=en_US")}

Run our application

Now that we have configured our application plugin we can use the tasks that it is providing to run our application directly.For that we simply run the run task either via the gradle tab in IntelliJ or via cli with ./gradlew run and gradlew.bat run.

Build and distribute our application

To distribute our application we can still simply execute our build task as before.The application plugin hooks into gradle and tells it that the build process is depending on it.Once we execute our build task we find our distribution under build/libs/distributions.You can now choose between a tar or zip depending on your liking.This jar contains our own application jar and the jar of every dependency imported as implementation in our build file.

Executing the application

To run our application we need to unzip the tar or zip and execute the sh or bat file inside the bin directory.And that's already it.Your application can run everywhere, where java is installed.

Thank you

Now you know the basics of the application plugin for gradle.If you want to know more I recommend looking at the official documentation.

Thanks for reading!If you liked this post, or have some questions, feel free to come by my discord and have a chat!

Or write me a mail at mail [at] chojo [dot] dev.

If you want to support me, feel free to sponsor me via GitHub.

Gradle Shadow Plugin

chojo — Mon, 26 Aug 2024 19:17:15 +0200

Gradle Shadow Plugin

The shadow plugin for gradle is a third party plugin that is widely used.It is especially useful if you need to bundle all your dependencies in a single jar, producing a so called FatJar.If you simply want to ship a standalone application, the application plugin might be the better choice.Shadow is ideal for minecraft plugins for example.

What is the shadow plugin

The shadow plugin will copy all your dependencies imported via implementation into your jar file during the building process.

It has also some additional features like relocating packages and setting the main class path, which I will explain later.

Applying the shadow plugin

Since the shadow plugin is a third party plugin we now need to define the version of it additionally.

plugins { id("com.gradleup.shadow") version "9.4.1"}

Our dependencies currently look like this:

dependencies { implementation("de.chojo.sadu", "sadu", "2.3.9")}

The purpose of shadow is to copy everything marked as implementation to the output jar.

This is already the case if we were to run the shadowJar task instead of the build task.However, building our plugin without shadowJar would result in a jar that is simply broken and would throw a ClassNotFoundException at us at the moment we want to use classes from SADU.

Configure shadow task

We can fix this by telling Gradle that when we run build we actually want to run shadowJar.We do this by configuring the build task to depend on shadowJar.

tasks { build { dependsOn(shadowJar) } shadowJar { mergeServiceFiles() }}

Additionally, we want to merge service files.

Service files

If you have dependencies that provide services (which a lot actually do) You should add mergeServiceFiles() to your shadowJar task configuration. This makes shadow to merge all service files of all your dependencies together.

tasks { shadowJar { mergeServiceFiles() }}

Minimize

If you have a very large jar because you have a lot of dependencies, it might be beneficial to minimize your jar. This will remove any uncalled class of your dependencies. But be aware that this will not detect classes loaded via reflections, e.g. database drivers.

tasks { shadowJar { minimize() }}

Relocation

Warn

This part is crucial when shading in minecraft plugins

Now that our libraries are shaded we need to do something called relocation.This is important to avoid conflicts with other plugins when you shade the same library.To do this we need to configure it, but this time we are not configuring the plugin, but the task called shadowJar.

tasks { shadowJar { val mapping = mapOf("de.chojo.sadu" to "sadu") val base = "dev.chojo.myapp.libs." for ((pattern, name) in mapping) relocate(pattern, "${base}${name}") }}

What this basically does is:

We define a map with the packages we want to move and the directory we want them to move to.
We define the root of the new location of all our shaded libraries.
For each entry in our map, we call the relocate function of our task.

So what does relocation do?
Consider the class de.chojo.sadu.Sadu. After the relocation it will be located at dev.chojo.myapp.libs.sadu.Sadu.Now that it is in your namespace and our plugin, it is no longer possible for it to collide with another plugin.Shadow will also replace any path to the class in your code with the new relocated path.

The path to relocate is usually the group id of the dependency you want to relocate.Beware that dependencies may have own dependencies that are shaded as well.Those dependencies might have other group ids that require explicit relocation.

Bundling applications

If your application is not a plugin, and you want to run your jar via java -jar you additionally need to define a main class. You can do that easily in the shadowJar task as well.

tasks { shadowJar { manifest { attributes(mapOf("Main-Class" to "dev.chojo.myapp.Main")) } }}

Checkpoint

plugins { id("com.gradleup.shadow") version "9.4.1"}group = "dev.chojo" // Please use your own group id c:version = "1.0.0-SNAPSHOT"repositories { mavenCentral()}dependencies { implementation("de.chojo.sadu", "sadu", "2.3.9")}java { toolchain { languageVersion = JavaLanguageVersion.of(21) } withSourcesJar() withJavadocJar()}tasks { build { dependsOn(shadowJar) } shadowJar { mergeServiceFiles() // minimize() val mapping = mapOf("de.chojo.sadu" to "sadu") val base = "dev.chojo.myapp.libs." for ((pattern, name) in mapping) relocate(pattern, "${base}${name}") // If you have a main class, relocation is most probably not necessary since your application is most probably standalone manifest { attributes(mapOf("Main-Class" to "dev.chojo.myapp.Main")) } }}

Thank you!

Thank you for sticking with me so far.You now have a very good understand how the shadow plugin works.

To continue your gradle journey you may be interested in my other blog post about gradle basics with minecraft, or you maybe want to take a look at the application plugin

Thanks for reading!If you liked this post, or have some questions, feel free to come by my discord and have a chat!

Or write me a mail at mail [at] chojo [dot] dev.

If you want to support me, feel free to sponsor me via GitHub.

Gradle with Minecraft

chojo — Mon, 26 Aug 2024 19:17:15 +0200

Gradle with Minecraft

This blog post is about minecraft development with gradle and some of the most crucial tools that make your life much easier.

This post assumes you have a build file similar to the one we had at the end of the first gradle blog post.

Creating a plugin.yml using a Gradle plugin

If you followed only the last blog post, you might not have a plugin.yml yet.If you already have a plugin.yml you can delete it now or wait until the end of this section.

To create our plugin.yml we will use the plugin-yml Gradle plugin.

Importing

First we need to import it.

Note

Although I do not have any other plugins in my plugin section at the moment, this does not mean that you should create a new plugin section or delete the other plugins.I just do not show all available plugins every time to keep it as short as possible.

plugins { id("de.eldoria.plugin-yml.bukkit") version "0.9.0"}

Configuration

Now that this is done, we need to configure our plugin.We do this, of course, in the section of the plugin called bukkit in our case.

bukkit { name = "MyPlugin" main = "dev.chojo.myplugin.MyPlugin" commands { register("test") { aliases = listOf("command") } }}

This is the minimum setup. (Commands are not really needed)What are we doing here?

We define the plugin with the name "MyPlugin".
We define our plugin class.
Please don't make it Main and choose a correct namespace. See my previous blog post.
We will register a command called test with the alias command.

Have a look at the GitHub page for further references.

The version is taken from your project version by default.

plugins { java id("de.eldoria.plugin-yml.bukkit") version "0.9.0"}group = "dev.chojo" // Please use your own group id c:version = "1.0.0-SNAPSHOT"repositories { mavenCentral() // External repository maven("https://repo.papermc.io/repository/maven-public/")}dependencies { compileOnly("io.papermc.paper:paper-api:26.1.2.build.63-stable") implementation("de.chojo.sadu", "sadu", "2.3.9")}java { toolchain { languageVersion = JavaLanguageVersion.of(21) } withSourcesJar() withJavadocJar()}bukkit { name = "MyPlugin" main = "dev.chojo.myplugin.MyPlugin" commands { register("test") { aliases = listOf("command") } }}

Bukkit Libraries - The better alternative to shading

Lets assume our dependency section looks like this:

dependencies { compileOnly("io.papermc.paper:paper-api:26.1.2.build.63-stable") implementation("de.chojo.sadu", "sadu", "2.3.9")}

Previously we had the problem that SADU was not included in our jar.If we use the plugin-yml plugin and are using Minecraft 1.16.5 or later, we can use the library loader.All we need to do is change implementation to bukkitLibrary:

dependencies { compileOnly("io.papermc.paper:paper-api:26.1.2.build.63-stable") bukkitLibrary("de.chojo.sadu", "sadu", "2.3.9")}

Now our library is loaded by Spigot/Paper when it loads our plugin and is available at runtime.This works because SADU is located at Maven Central and Spigot/Paper downloads libraries from there.Libraries not located at Maven Central still need to be shadowed.

Paper plugins

Paper plugins are a type of plugin exclusively for Paper servers.They are quite new and some things might be different from what you know.They don't share the command system with spigot but use the Brigadier system, that Minecraft itself uses. Usually people use a command system like Cloud or ACF, which wraps around Brigadier and maker it easier to use.They also require a new configuration framework, since file configurations and ConfigurationSerializable are no longer available. I developed jackson bukkit for that.So the learning curve might be a bit steeper for beginners since you probably start with a bunch of new frameworks right from the start. But if you are very new to this and are just starting with minecraft and are just targeting newer paper server, this might be an interesting starting point.

In Paper plugins you can also load dependencies from custom repositories. You can read more about this here.

More about Paper plugins can be found here and here.

Checkpoint

plugins { java id("de.eldoria.plugin-yml.bukkit") version "0.9.0"}group = "dev.chojo" // Please use your own group id c:version = "1.0.0-SNAPSHOT"repositories { mavenCentral() // External repository maven("https://repo.papermc.io/repository/maven-public/")}dependencies { compileOnly("io.papermc.paper:paper-api:26.1.2.build.63-stable") bukkitLibrary("de.chojo.sadu", "sadu", "2.3.9")}java { toolchain { languageVersion = JavaLanguageVersion.of(21) } withSourcesJar() withJavadocJar()}bukkit { name = "MyPlugin" main = "dev.chojo.myplugin.MyPlugin" commands { register("test") { aliases = listOf("command") } }}

NMS and internals using the Paperweight Userdev plugin

I do not encourage using nms in any way, but if you want to, you should use the userdev plugin from paperweight.This allows you to develop against an environment with non-obfuscated names.It is also the only supported way of accessing internals in org.bukkit.craftbukkit.v1_XX_RX.It also ensures that when you upgrade to a new version, you do not have to change any code that is using the net.minecraft package.Of course, you still need to change code when Mojang changed something.However, you still need to change the package names when using internal code from org.bukkit.craftbukkit.v1_XX_RX;

Adding the repository

For this we need to do something new and go into our settings.gradle.kts to add a plugin repository.

pluginManagement { repositories { gradlePluginPortal() maven("https://repo.papermc.io/repository/maven-public/") }}

To do this we need to configure the pluginManagement section and change the repositories.By default, only gradlePluginPortal() is imported, which usually contains all the important plugins so far.But now we want to add another repository.It is very important that you add gradlePluginPortal() as well as the Paper repository.

Importing

Now we can import the plugin into our build.gradle.kts file.

plugins { id("io.papermc.paperweight.userdev") version "1.7.7"}

This leaves just one step to set up the Paper version.

Configuration

To define the version we want to use, we need to add it to our dependencies.To do this we need to remove the old Paper compileOnly dependency and replace it with the paperweight dependency.

dependencies { paperweight.paperDevBundle("26.1.2.build.63-stable")}

The version entered here is the same as for Paper. You just remove the group and artefact id.Paper uses the obfuscated jar.This requires us to actually reobfuscate our jar before building.We can do this again by configuring a task.This time we configure the assemble task and set a dependsOn on it.

tasks { assemble { dependsOn(reobfJar) }}

Note

From 1.21 onwards paper uses a non obfuscated jar.If your plugin only runs on paper, you no longer need to reobfuscate your jar.Have a look at the paper documentation, since some additional stuff is required to run mojang mapped plugins

And that's it.Now you can use nms as comfortably as possible.

Checkpoint

**build.gradle.kts**

plugins { java id("de.eldoria.plugin-yml.bukkit") version "0.9.0"}group = "dev.chojo" // Please use your own group id c:version = "1.0.0-SNAPSHOT"repositories { mavenCentral() // External repository maven("https://repo.papermc.io/repository/maven-public/")}dependencies { paperweight.paperDevBundle("26.1.2.build.63-stable") bukkitLibrary("de.chojo.sadu", "sadu", "2.3.9")}java { toolchain { languageVersion = JavaLanguageVersion.of(21) } withSourcesJar() withJavadocJar()}bukkit { name = "MyPlugin" main = "dev.chojo.myplugin.MyPlugin" commands { register("test") { aliases = listOf("command") } }}

**settings.gradle.kts**

pluginManagement { repositories { gradlePluginPortal() maven("https://papermc.io/repo/repository/maven-public/") }}

Running a server with your jar

To quickly test your plugin, you can start a server directly.All you need to do is add the run-task plugin to your build file.

I'll refrain from simply copying their readme here, as I can't add any more value to it.

Thank you!

Thank you for sticking with me so far.You now have a very good understanding of Minecraft development with Gradle.

Thanks for reading!If you liked this post, or have some questions, feel free to come by my discord and have a chat!

Or write me a mail at mail [at] chojo [dot] dev.

If you want to support me, feel free to sponsor me via GitHub.

GPN22 Tag 4 | Das Ende und der Anfang

chojo — Sun, 02 Jun 2024 16:23:55 +0200

GPN22 Tag 4 | Das Ende und der Anfang

Der letzte Tag der GPN beginnt wieder früh um halb neun. Obwohl ich super Müde bin, steht jetzt schon fest: Ich komme wieder und hoffentlich wird das der Anfang einer neuen jährlichen Tradition.

Eigentlich wollte ich ausschlafen und es langsam angehen lassen, aber natürlich war um 10 Uhr doch noch ein Talk, den ich sehen wollte. Es ging um "Big Data Analysis with SQL". Vermutlich hatte ich aber zu hohe erwartungen an den Talk. Die erste hälfte des Talks war lediglich basic SQL Erklärung, auf die ich gut hätte Verzichten können. Der zweite Part fühlte sich mehr an wie Technologiebingo. Eine Menge namen und Beispiele und zum Schluss noch ein grobes Architektur Diagram. Der Kern des ganzen ging auch eher um statische Aggregation und Statistiken, wofür ich keine wirkliche verwendung habe.

Also wieder zurück zum Platz. Die zwei Jungs von den letzten zwei Tagen waren auch schon wieder da. Nach einiger Zeit gesellte sich Nick wieder hinzu und auch Hannes und Johnny stießen recht schnell wieder hinzu. Irgendwann stellte sich dann noch heraus, dass einer der beiden Jungs sogar bereits auf dem DevCord war und so gar es eine neue Verbindung und wir werden vermutlich auch nach der GPN noch Kontakt halten. Nach ein paar letzten Stunden die viel zu schnell bei Gesprächen und programmieren vorbeigingen, war es dann auch so weit.

Als ob jemand einen Hebel umgelegt hatte, schwing alles um auf Abbau. wir schlossen und dem nach einiger Zeit auch an, machten unsere Tische leer und halfen auch noch ein bisschen Tragen. Da Nick jedoch auch bald zum Zug musste und sich bei uns allgemein der Hunger langsam bemerkbar machte, ging es kurz zum Hotel damit ich etwas Zeug loswerden konnte. Nick verabschiedete sich und unsere nun recht kleine Truppe auf Johnny, Hannes und mir beschloss mich in das Oxford mitzunehmen. Einem Ort, von dem ich zumindest bereits gehört hatte und der angeblich recht gute Burger anbieten sollte.

Nach einer recht kurzen fahrt und einem kleinen Spaziergang waren wir auch schon in einem recht schönen Pub. Ich struggelte wie immer an einer entscheidung, was ich essen und trinken sollte. Am Ende viel die Entscheidung natürlich auf einen Burger und ein schönes alkoholfreies Paulaner. So ließen wir die GPN gemütlich ausklingen bei einem letzten Gespräch, bevor sich dann auch Hannes verabschiedete.

Ich hatte jedoch noch Lust auf ein bisschen Kuchen und Johnny zeigte mir noch das "intro", das sich schöner Weise praktisch um die Ecke befand. So gönnten wir uns noch einen Cappuccino und ich mir einen echt leckeren Cheesecake. Nach einiger Zeit war es jedoch auch hier Zeit erneut Abschied zu nehmen.

Ich setzte mir meine Kopfhörer auf und trat zu "Born this way" als Nightcore version meinen Rückweg an zur Tram Station. Und vermutlich gibt dieses Lied auch eine gute Stimmung der GPN wieder. So viele Bunte und unterschiedliche Menschen auf einem Haufen. Jede:r konnte so sein wie man sich fühlte und wer man sein wollte. An wenigen Orten fühlte ich mich tatsächlich so frei persönlich wie auf der GPN. Tatsächlich ein wirklicher Safespace für so viele. In einem Talk wurde auch erwähnt, dass die GPN die vermutlich diverseste Veranstaltung im CCC ist. Ohne je auf einem anderen CCC Event gewesen zu sein, glaube ich das gerne und finde es wundervoll.

Beim Schreiben dieses Posts und dem Blick zurück auf das Wochenende kommt tatsächlich auch ein Tränchen. Ich bin glücklich, dass ich dabei war, aber definitiv auch traurig, dass es schon vorbei ist. Die vier Tage gingen super schnell vorbei. Wenn ich aber so in mich hinein fühle, hätte ich vermutlich keinen 5. Tag mehr mitgemacht. Ich bin müde und meine Social Battery war schon lange nicht mehr so leer wie sie gerade ist.

Mein Framework hat mittlerweile kaum mehr einen freien Platz und ich liebe einfach wie das geendet ist. Es wird mich immer an dieses schöne Wochenende erinnern.

Natürlich wäre die ganze GPN nichts ohne Entropia und die ganzen Trolle die überall geholfen haben. Für mich ist klar, dass ich nächstes Jahr definitiv auch Trollen möchte um etwas zurückzugeben.

Jetzt sitze ich in meinem Hotel und werde den Abend noch schön ausklingen lassen. Vielleicht etwas serie schauen, wenn das Internet mitmacht oder vielleicht noch etwas mit meinen Katzenohren durch die Stadt laufen und Musik hören. Aber egal wie ich mich entscheide, eins ist klar. Ich komme nächstes Jahr wieder und ich kann es kaum erwarten.

GPN22 Tag 3 | Nix ist ne ganze Menge

chojo — Sat, 01 Jun 2024 19:12:24 +0200

GPN22 Tag 3 | Nix ist ne ganze Menge

Tag drei begann in etwa genauso wie Tag zwei. Diesmal stand ein Nix Talk am morgen an und daher war später aufstehen nicht wirklich eine Option.

Also aufstehen, duschen, frühstücken und ab zur GPN. Diesmal zu Fuß um zumindest ein bisschen Bewegung zu haben. Angekommen wurde dann erstmal noch schnell der Blog Eintrag für Tag 2 fertig gemacht und hochgeladen.

Der NixOS Talk mit dem Namen "Von Nix kommt Nix" war überraschend informativ und auch super differenziert, was Vor- und Nachteile angeht. Gepaart mit gelegentlichen lachern, obligatorischen Nix Witzen und anderem. Klare empfehlung. Die Flakes erscheinen mir jedoch immer noch wie schwarze Magie. Der Talk selbst war dabei super high Level. Ich hatte anderes erwartet, aber was ich bekommen habe, war auch gut.

Zurück am Platz hat Nick das bytecode patching gelöst, was letzte Nacht immer noch nicht funktioniert hatte. Nach einiger Zeit haben wir dann auch den Fehler in meinem Code gefunden, welches am Ende natürlich nur eine fehlende Negierung eines if war.

Eine neue Runde am Stickertisch bescherte mir wieder ein paar Neuzugänge und ein italiener der bei unserer CTF Gruppe mitgemacht hat, hat einfach mal eine Familienpizza bestellt. Etwas später wollte ich mich dann bei einem Talk Besuch mit Johnny und Nick anschließen zum Thema Energiemonitoring anschauen. Der war jedoch voll und am Ende landeten wir in einem Talk über Zivilcourage. Ein emotionaler aber auch informativer Talk, wie man mit kritischen Situationen umgeht und wie man am besten Menschen in Bedrängnis hilft.

Eigentlich wollte ich den darauffolgenden Talk über Rest in the Cloud sehen, aber die Stühle haben mir echt Rückenschmerzen verursacht. Und nachdem ich die Schlange beim Herausgehen gesehen habe, war bereits klar, dass ich definitiv nicht wieder reinkomme, jetzt wo ich den Saal verlassen hatte. Also ging es zurück zum Platz. Blog schreiben, reden und noch mehr. Gegenüber haben sich außerdem eine Familie aus Koblenz niedergelassen, mit denen wir am letzten Abend schon etwas Kontakt hatten. Die begeisterung der beiden Jungs mir gegenüber, während sie ihren Bot (Ich vermute für das Snake Battle hier vor Ort) beim gelegentlichen Gewinnen zujubelten war wirklich wundervoll.

Gegen Nachmittag schaute Lynx dann noch vorbei, der uns von Zeit zu Zeit gesellschaft leistete.

Der Talk über die ePA war mit Abstand einer der besten Talks bisher. Ich wünschte, ich hätte so einen technisch Interessierten und offenen Hausarzt. Die behandelten Themen fühlten sich spot on an und auch für mich habe ich eine Menge mitgenommen and möglichen "Krankheitsbildern", die eigentlich gar keine sind und eher gesellschaftlich so behandelt werden. Ich kann wirklich nur empfehlen diesen Talk online nachzuschauen wenn möglich. Auch wenn gegen Ende etwas abgedriftet wurde, fand ich Konzepte wie informationelle Krankheit super interessant und sollten allgemein mehr Aufmerksamkeit erhalten.

Frisch nach dem Talk erinnerte ich mich, dass ja die neue NixOs Version seit letztem Abend verfügbar ist. Da der ganze Spaß mein erstes major Update ist, gab es erstmal viel Unbekanntes. Schönerweise waren die NixOS docs aufschlussreich. Kurz den stable und Home Manager Channel geändert, kurzes update und das rebuilden konnte schon beginnen. Nach dem ersten restart jedoch noch nichts. Also zurück in die Config. Alles richtig, also nochmal meine scripte ausgeführt und diesmal passierte tatsächlich was. Ein restart später und die GEwissheit war da, dass ich erfolgreich auf 24.05 geupdated habe. Das einzige Fehlende war nun noch Plasma 6, aber das war auch mit einer Zeile erledigt. Johnny motivierte mich dann noch dazu meinen fingerprint reader endlich mal einzurichten und zeigte mir das wunderbare nixos-hardware repository, dass natürlich auch extras für mein Framework enthielt.

Nach diesem erfolgreichen Update war es endlich Zeit zum Essen. Durchaus verdient würde ich sagen. Statt dem guten Soja Gulasch gabs schönes Kartoffelgulasch, vor allem weil die Wartezeit für das Soja Gulasch eher richtung einer Stunde ging und das Kartoffelgulasch ziemlich sofort verfügbar war. Danach gabs dann noch die wunderbaren Waffeln. Großes Lob an die GPN, dass man wirklich überall mit Karte bezahlen kann. Die Apotheke um die Ecke bei mir würde Staunen.

Nach weiteren Gesprächen und dem Verbreiten von Nix Propaganda habe ich natürlich den Beginn der Nix Meetups verpasst. Ich hab mich dann dennoch mit Duckie in das Meetup geschlichen und ein paar Sticker ergattert. Die Luft da drin war jedoch so warm und Stickig, dass ich nicht wirklich lange ausgehalten hab. War wohl Nix.

Also wieder zurück zum Platz und die erhaltene Nix Sticker auf dem Laptop anbringen. Das war so ziemlich mein absoluter Milestone den ich erreichen wollte. Außerdem stellte sich heraus, dass die Person mir gegenüber auch bei der Feuerwehr ist und es entspannte sich ein recht langes und unterhaltsames Gespräch über dies und das. Grüße gehen raus an der Stelle, wenn du das liest!

Im Laufe des weiteren Abends ergatterte ich eines dieser coolen LED Namensschilder, mit denen schon super Viele herumgelaufen sind. Das musste ich das natürlich auch haben. Wir fanden die Entwickler im zweiten Stock, den ich nach dem Nix Meetup jetzt zum zweiten Mal betreten hatte. Nach kurzem Suchen wurde uns der Standort der zwei Schöpfer offenbart und für 25€ gabs ein Stück Hardware mit zugehöriger App. Während die App bereits Open Software ist, ist es die Hardware noch nicht, aber man versprach zum Congress da auch nachzubessern.

Die Aussicht aus dem zweiten Stock nutzen wir dann noch für ein paar künstlerische Bilder, um das Farbenspiel festzuhalten, dass sich unter uns erstreckte. Wieder unten angekommen habe ich viel zu lange noch beim KITCTF Spawn gesessen. Heim ging es dann am Ende wirklich erst gegen kurz vor zwei. Motiviert, wie ich war, wollte ich noch am Abend den Blog post fertig schreiben für heute. Das hab ich jetzt hiermit getan. Es ist halb drei... Das wird ein lustiger morgen.

GPN22 Tag 2 | Balkonkraftwerke und andere Pfuschereien

chojo — Sat, 01 Jun 2024 10:38:51 +0200

GPN22 Tag 2 | Balkonkraftwerke und andere Pfuschereien

Der zweite Tag begann früh um halb 9. Nach einer schnellen Dusche und einem ausgiebigen Frühstück ging es schon um kurz vor 10 los zur GPN. Unsere Sitzplätze waren leider bereits belegt und nur noch unser Haufen an Campingstühlen zeugte von unserer Existenz an diesem Ort.

Spontan nahmen wir zu zweit den noch freien Tisch des Koblenzer Hackerspace ein, die uns netterweise Asyl gewährten während ich struggelte eine meiner Minecraft Plugins in eine Library zu verwandeln und irgendwie zu verstehen was FAWE mal wieder da treibt.

Um 12 stand dann ein super informativer Talk über Balkonkraftwerke an. Eine wunderbare präsentation kombiniert mit einem super freien und actually mitreißenden Vortrag. Und das, obwohl es um gesetzestexte, langsame Politik und Ministerien ging. Für mich steht damit erneut fest, dass ich mir definitiv ein Balkonkraftwerk besorgen werde, sobald die Gesetzesänderung durch ist, dass mein Vermieter mir erlauben muss eines anzubringen.

Nach dem Talk ging es erneut zum Stickertisch und ich erbeutete noch ein Cuttermesser, um die Ränder sauber abzuschneiden. Mittlerweile ist er relativ voll. Vielleicht denke ich ja daran, hier noch ein Bild einzufügen.

Danach ging es mit ein bisschen code Pfuscherei für das KIT CTFi weiter. Ich schrieb das erste Mal PHP Code und bin froh mit dieser Sprache offensichtlich nichts verpasst zu haben. Nach ein paar frustrierenden Anlaufen nach einem guten Start und einem Multithreaded Approach mittels Bash Script gehts zu einem neuen Talk. Diesmal über Computer bauen. In dem Fall ein 8 Bit Computer mit Relais. Nach einer recht trockenen aber auch informativen Einführung wurde doch tatsächlich ein 8 Bit "Computer" zusammen gebaut. Und das Klicken der Relais löste nach 30 minuten Talk und Graphen doch schon eine gewisse Euphorie im Raum aus. Eine bessere Zielgruppe für so etwas gibt es vermutlich nicht. Gib einer Gruppe von Technikbegeisterten etwas was sie mit blinkenden Lichtern sehen und durch Klicken hören können und du hast alles, was du brauchst.

Nach dem Talk hatte ich endlich die Chance besagtes Ramen Restaurant auszutesten, dass ich am Anreisetag nicht besuchen konnte. Mein Shoyou Ramen war wirklich ausgezeichnet und auch die obligatorischen Takoyaki waren wunderbar. Auf unserer Suche nach einem Eisladen standen wir für einen kurzen Moment etwas Ratlos in der gegend herum und wurden prompt von einer Frau angesprochen die im kleinsten begehbaren Laden Deutschlands? arbeitet, wie sie stolz betonte. Sie wies uns netterweise den Weg zur Eisdiele die peinlicherweise nach 10 Metern direkt um die Ecke lag. Frisch gestärkt mit essen und nachgezuckert mit Eis ging es dann zurück auf die GPN wo ich mich entschloss erstmal den Blogpost für Tag 2 zu schreiben, bevor ich nochmal den Sticker Tisch auschecke.

Den nächsten Talk skippe ich, um mal wieder etwas Zeit für mich zu haben und nicht permanent von Event zu event zu hasten. Stattdessen widme ich mich einem kleinen Projekt, dass ich bereits etwas länger auf meinem Tisch habe. Angus Mail bescherte mir wie erwartet eine "riesen" Freude, aber nach einiger Zeit ist der Mail Support auch gefixed. Währenddessen hat sich eine andere Gruppe zu uns gesellt und es entwickeln sich angeregte Gespräche über DevOps, NixOs und die Frustration und Freuden mit aktuellen und vergangenen Betriebssystemen. So angeregt, dass ich spontan auch meinen 20 Uhr talk verpasse und damit auch die Chance meinen Merch den ich bestellt habe abzuholen.

Ich wende mich wieder der programmierung zu. Es ist mittlerweile recht spät. Doch späte Zeit bringt oftmals doofe Ideen. Ziel war es eigentlich einfach nur einen String in einer kompilierten class Datei zu ersetzen innerhalb einer Jar. Natürlich könnte man jetzt hingehen und mit ASM die klase auseinandernehmen und in den constants danach zu suchen. Nick empfand es jedoch als deutlich interessanter die Bytes der Klasse nach den Java Specs auseinander zu nehmen und den ganzen Spaß mit plain Java zu lösen. Währenddessen schaute ich beim KIT Tisch vorbei wo ein Freund derzeit ein Gästebuch im internen LAN Netz exposten um zu sehen wie viele Leute so den Spaß durch zufällige Portscans finden.

Nachdem ich mit Waffeln zurück zu unserem Tisch gelockt wurde, war zufällig auch die erste Iteration des Bytecode Replacers durch. Da ich dennoch eine Pause brauchte, schaute ich erneut beim Stickertisch vorbei und ergaunerte ein paar neue Schätze. Der Laptop ist mittlerweile fast voll und noch zwei Tage sind verbleibend. Läuft besser als gedacht.

Um 1 Uhr traten wir dann langsam den Heimweg an. Auf die Party verzichtete ich mal mangels Energie. Auch wenn die Bässe echt gut klangen.

GPN22 Tag 1 | Die erste GPN

chojo — Fri, 31 May 2024 18:15:48 +0200

GPN22 Tag 1 | Die erste GPN

Nach einer morgendlichen Dusche und einem überraschend üppigen Frühstück im Hotel stand noch etwas arbeit an.

Während Freunde bereits Bilder von der noch nicht ganz so startbereiten GPN schicken und plätze reserviert haben für uns, saß ich in meinem Hotelzimmer und löste noch ein paar Probleme an der Arbeit und fasste den Entschluss wirklich einen Blog über meine GPN Erlebnisse zu schreiben.

Um 14 Uhr kam Nick vom DevCord an, der im selben Hotel wie ich untergekommen ist. Nach einem kurzen Hallo und der Übergabe meines alten Laptops für die GPN ging es dann auch schon los mit der Tram. Die zwei stationen hätte man auch einfach laufen können, aber gut. Spontan natürlich an der weniger optimalen Haltestelle ausgestiegen gabs noch einen kleinen Fußweg, bis ich endlich das Gebäude erblickte, in dem ich mich die nächsten Tage vermutlich vorwiegend aufhalten werde.

Die GPN war auch irgendwie ein inoffizielles DevCord treffen. Zu unserer Gruppe gehörten daher neben Nick außerdem daher auch Marie mit Anhang, Johnny, SirYwell, MeinerLP mit OneLiteFeather und noch mehr. Duckie haben wir irgendwann adoptiert. Er saß einfach neben uns und irgendwann haben wir festgestellt, dass er einfach so Teil unserer Gruppe geworden ist.

Das Gebäude der ZKM ist überraschend groß. Obwohl ich nicht wirklich weiß, was ich erwartet habe, war ich überrascht, wie groß das ganze doch ist. Und obwohl es praktisch offiziell gerade mit dem ersten Talk losging, war es schon überraschend voll. Die Technik bandbreite selbst reichte von kleinen Minipcs, die noch recht gewöhnlich sind über CRTs bis hin zu stapeln von Server und einer wahren Armee von 3D Drückern die über die Zeit überall im Raum gespawned sind.

Was jedoch noch bunter gemischt als die Technik war, waren die Menschen, die sie mitbrachten. Ich vermute kaum, dass es wirklich vielfältigere Orte gibt als diese Events. Furries, normal erscheinende Menschen, eine Menge an Ohrentragenden wesen und alles dazwischen. Eigentlich gibt es nichts was man vermissen müsste. Vermutlich findet hier wirklich jede:r eine Gruppe an die man sich hängen kann. Der Sitznachbar wird zum Gesprächspartner und später geht man dann sogar zusammen essen und es fühlt sich mehr an als ob man sich bereits längere Zeit kennt. Ich denke vor allem die Gemeinschaft hier ist, was dieses Event wirklich besonders macht.

Ich sitze jetzt hier an Tag 2 und auch wenn ich es vermutlich nicht viel machen werde, sind die wenigen Gespräche die ich hier mit einzelnen Personen hatte wirklich hängen geblieben.

Unsere Gruppe ist relativ groß. Um die 8-10 Leute. An unserem Tisch ist ein ständiges Kommen und Gehen. Einige reisen von weiter weg an, aber irgendwer ist eigentlich immer an unserem Platz. Ansonsten sind bekannte von mir auch relativ über die Halle verteilt. Auch wnn es jetzt nicht so ist, dass ich viele hier kenne. Aber am Ende lernt man natürlich immer neue Menschen kennen.

Zum Anfang gab es weder LAN noch WLAN. Letzteres war zwar technisch existent, mit Übertragungsraten im unteren KB Bereich aber nicht wirklich Nutzbar. Abhilfe wurde mit Hotspots geschaffen über anderen Interne Netzwerke. Der Mobilfunk war natürlich mit der Masse an Geräten an einem Punkt natürlich Maßlos überfordert. Zum Glück besserte sich das im Laufe des Tages (Zumindest das LAN und WLAN). Während neben mir fleißig gestruggelt wurde meinen Laptop mit NixOS aufzusetzen, stellte sich dd erneut als wunderbarer Freund heraus, wenn man einfach einmal den inhalt einer Festplatte wipen wollte, wenn das OS selbst andere Pläne hatte.

Wie zu erwarten war ich mit meinem neu erworbenen Framework absolut nichts Besonderes und das an einem anderen Tag stattfindende Nix Meetup erscheint angesichts der Masse an Nix Nutzern hier eher wie ein Joke. Ein Meetup für nicht Nix Nutzer erscheint mir hier eher einfacher, aber wir werden ja sehen.

Eines meiner Ziele für die GPN war die Oberseite meines Laptops mit Stickern zu dekorieren und am Ende im idealfall kein sichtbares Aluminium mehr zu haben. Nachdem mir die existenz des Stickertisches offenbart wurde gabs kein halten mehr und die ersten Sticker zierten bereits meinen schönen Laptop. Mehr werden bestimmt in den nächsten Tagen folgen.

Natürlich besteht dieses Event nicht nur aus Leuten die in einer Halle zum Sitzen und auf ihre Bildschirme starren. Um uns herum gibt es überall super interessante vorträge. Leider habe ich von dreien bereits zwei verpasst. Den ersten hatte ich schlichtweg "verschlafen" und beim zweiten war fünf Minuten vorher definitiv mehr als 5 Minuten bereits zu spät. Der Talk am Abend der über Probleme bei Rechenzentren gehen sollte war zwar unterhaltsam, hat jedoch nicht ganz so den Wert gehabt, den ich mir erhofft hatte. Hoffentlich sind die Talks am zweiten Tag interessanter und ich komme auch rein.

Am Abend stand dann noch etwas socialisen auf dem Programm und Leute nerven und sie nach ihren Projekten ausfragen. Die Gruppe am Nachbartisch hatte einen 3D Drucker und verschenkten 3D gedruckte Haarreife mit Katzenohren. Natürlich konnte ich da nicht widerstehen und ergatterte ein oranges Paar. Um kurz nach zwölf ging es dann Richtung Hotel. Diesmal jedoch zu Fuß. Wie sich herausstellt, ist der Weg zum Hotel eigentlich nur geradeaus und das wars. Nach 10 Minuten viel ich auf mein Bett. Noch kurz alle Geräte zum Laden angesteckt und dann war das Licht aus. Immerhin konnte ich rausschlagen erst um 9 Uhr zum Frühstück zu gehen.

GPN22 Tag 0 | Anreise

chojo — Thu, 30 May 2024 10:37:35 +0200

GPN22 Tag 0 | Anreise

Da dies meine erste GPN sein wird dachte ich, dass ich meine Erlebnisse gern mal auf meinem Blog festhalten möchte. Vorwiegend als experiment für mich.

Die Anreise war bereits am Mittwoch. Ich mag entspanntes Reisen und tauche ungern irgendwo müde von einer mehrstündigen Bahnreise auf.

Bahn Tickets wie immer im Voraus gekauft. Als erfahrener Bahn Reisender weiß man wie das geht. Wie immer kam dann bereits einige Wochen vor der eigentlichen Fahrt die erste Mail, dass mein Zug leider nicht so fährt wie ich ihn gebucht habe. Der ICE 77 fährt jetzt eine Stunde früher und kommt genauso spät an wie vorher. Das ist natürlich schlau. So muss die Bahn natürlich nichts erstatten, obwohl ich persönlich eine Stunde länger auf meiner Reise unterwegs bin. Und all das nur, weil man jetzt Krampfhaft versucht alle Baustellen vor der EM fertig zu bekommen, damit zumindest mal für einen Monat die Züge halbwegs planmäßig Fahren können.

Anstatt jedoch einfach mein Ticket auf die Alternative Verbindung umzubuchen, welche auch vom ICE 77 bedient wird, hebt die Bahn meine Zugbindung auf und damit verschwindet auch meine Sitzplatzreservierung im Nirvana. Also auf neue Sitzplatzreservierung für denselben Zug erneut Buchen. Wenn man sich denkt, dass garantiert nicht alle ihre 5 € dafür zurückfordern gibt das auf Dauer bestimmt ein bisschen extra Geld. Aber die Bahn hat es ja auch nötig.

Und immerhin gibt sich die Bahn alle mühe und terrorisiert einen nahezu jetzt mit E-Mails und Push-Benachrichtigungen damit man auch auf keinen Fall nicht sieht, dass die Verbindung so nicht funktioniert. Allerdings erst vier Tage vorher. Wenn man nicht regelmäßig (Bei mir mindestens einmal pro Woche) die geplanten Verbindungen selber prüft, bekommt man das so relativ spät erst mit, dass sich eventuelle Pläne geändert haben.

Während ich mich jetzt also eine Stunde früher als geplant zum Bahnhof begebe, ist der ICE tatsächlich pünktlich. Meine neue Sitzplatzreservierung steht nicht am Sitzplatz und da genug freie Plätze die anscheinend nicht reserviert sind frei sind, verzichte ich auf das Verjagen der Personen auf meinem reservierten Platz. Gerade in den Sitz gefallen fällt mir jedoch auf, dass ich meinen geliebten Campingstuhl vergessen habe. Tja, das wars wohl erstmal mit gemütlich sitzen auf der GPN. Aber Karlsruhe ist immerhin kein Dorf, also wird man sich dort vermutlich auch einen neuen Stuhl besorgen können.

Meine Pläne am Donnerstagmorgen mir schnell noch einen Stuhl zu besorgen werden im DevCord jedoch schnell zerschlagen. Im gegensatz zum gottlosen Berlin ist in Baden-Württemberg morgen ein Feiertag und nichts mit einkaufen.

Auf der Fahrt nach Karlsruhe gebe ich mich ausnahmsweise mal Podcasts hin. Und während ich dem SZ Podcast zu den Wirecard prozessen lausche, die überraschend interessant und unterhaltsam sind, zieht draußen Deutschland vorbei.

Während ich mich Karlsruhe nähere begebe ich mich auf die Suche nach einer gescheiten App für den Karlsruher ÖPNV. Am Ende setzt sich jedoch Google Maps durch zum Navigieren und der DB Navigator zum Ticket kaufen. Die offizielle App hat mich nicht überzeugt. Aber vielleicht erwarte ich nach der BVG App auch einfach zu viel. Das Karlsruhe Waben hat und es nirgends einfach eine Erklärung gibt die groß eine solche ist, wähle ich einfach die Tageskarte aus und gut ist. Für ein Deutschlandticket nutze ich leider absolut nicht genug ÖPNV.

Um 17 Uhr, fast pünktlich auf die Minute, erreichen wir dann Karlsruhe. Die Fahrt zum Hotel geht dank Maps also unkompliziert. Nach einem kurzen Einchecken im Hotel, das dank online Check-In und Schlüsselbox mit Pin ohne jeglichen menschlichen Kontakt abläuft, gehts also wieder raus auf die Straße.

Der Decathlon ist schnell mit der Bahn erreicht. Die Karlsruher Straßenbahnen haben einen echt guten Takt, oder die gegenden in denen ich unterwegs bin sind einfach nur gut angebunden. Ich besorge mir also einen neuen Campingstuhl und widerstehe auf dem Rückweg mich beim IKEA mit HotDogs einzudecken.

Zurück im Hotel lade ich schnell meinen Stuhl ab und nach einer kurzen Verschnaufpause gehts wieder raus auf die Straße. Da die Straßenbahn gerade kommt, nehme ich die und bin nach zwei Stationen in der Innenstadt (vermute zumindest, dass es hier nur eine gibt). Auf dem DevCord wurde mir eine Ramen bar empfohlen. Die ist jedoch so voll, dass ich in der nächsten Stunde vermutlich keinen Platz bekommen hätte. Da es mittlerweile 20 Uhr ist in mein Mittagessen solide 8 Stunden her ist, habe ich jedoch nicht mehr die Ausdauer so lange zu warten. Versuche ich es halt morgen nochmal.

Am Ende wird es das Frittenwerk, wo ich mir die vegetarische Currywurst mit Pommes gönne. Ausgewogene Ernährung kann ich. Den Weg zurück zum Hotel laufe ich, um mich zumindest ein wenig besser zu fühlen.

Zurück im Hotel wird das obligatorische HDMI Kabel an den Fernseher angeschlossen und mit ein wenig Fire Force der Abend beendet.

Sharing and Publishing Dependencies with Gradle

chojo — Wed, 14 Feb 2024 12:41:00 +0100

German Version

Reusing or accessing code from other projects with gradle is very easy.This blog posts dives into publishing dependencies to your local maven repository (or remote) to use it in another project.We also take a short look at online repositories and the small extras you have to account for when your projects are minecraft plugins.

If you are not familiar with gradle yet, have a look at my previous post about gradle basics.

Project Setup

We have two projects which are named Project A and Project B for simplicity.In the end Project A will implement code and functions that are used by Project B.

Since this is the more complex setup we're going to start with this.

Project A - The Provider

Project A will provide code accessed by Project B.That means we need to do several things:

Create a new gradle project named Project A
Add some logic/code to it, that we want to use in Project B
Publish our project into our local maven repository

Let's start with the setup itself. The configuration for our project and our class we want to use in our other project look like this:

build.gradle.ktssettings.gradle.ktssrc/main/java/dev/chojo/projecta/ProjectA.java

For now we take it simple.We defined our group and version.No dependencies and no additional repositories.

plugins { java}group = "dev.chojo"version = "1.0.0"repositories { mavenCentral()}dependencies {}

Nothing special here

rootProject.name = "project-a"

For demonstration purposes we only have one class with one method.

package dev.chojo.projecta;public class ProjectA { /** * Prints "Meow" to the console. */ public void meow(){ System.out.println("Meow"); }}

Now that we have our basic project setup we can work on publishing our changes.This is fairly simple.All we need to do is to import the maven-publish plugin and configure it.

Note

Some parts that were already there were left out now.Only parts that were changed are shown.

plugins { java `maven-publish`}java { toolchain { languageVersion.set(JavaLanguageVersion.of(21)) } withSourcesJar() withJavadocJar()}publishing { publications { create<MavenPublication>("maven") { from(components["java"]) } }}

A lot happened here, so lets go through it step by step.

We added maven-publish to our plugins. This allows us to publish artifacts in the first place
We configured the java plugin:
1. We defined the language version our library will use
2. We defined that we want to create a jar containing our source
3. We defined that we want to create a jar containing our javadocs
We configured the maven-publish plugin.
1. We created a new publications section
2. In that section we created a new MavenPublication called maven
3. We defined that this publication should return all components returned by our java plugin. This will be:
  - One jar containing our compiled code
  - One jar containing our source code
  - One jar containing our java docs

Now that this is done we can publish into our maven local by executing the publishToMavenLocal task of gradle.

Transitive dependencies

If your api depends on another api you can tell this to others.Instead of using implementation in your dependencies section you use api.For that you also need to import java-library as a plugin.

plugins { java `maven-publish` `java-library`}dependencies { api("de.chojo.sadu", "sadu", "2.3.9")}

This will make them import the library your depend on as a transitive dependency as well.

Project B - The Consumer

Now that we published our artifacts into our local maven repository we can access it from other projects on our system.

Warning

If you send your Project B to someone else they need to execute the publishToMavenLocal task themself on Project A.To properly share dependencies you should use remote repositories.The local maven repository should only be used for debugging and general testing of your project.

First we create our basic project setup again like we did on Project A.

build.gradle.ktssettings.gradle.ktssrc/main/java/dev/chojo/projectb/ProjectB.java

We defined our group and version.No dependencies and no additional repositories yet.

plugins { java}group = "dev.chojo"version = "1.0.0"repositories { mavenCentral()}dependencies {}

Nothing special here

rootProject.name = "project-b"

package dev.chojo.projectb;public class ProjectB { public static void main(String[] args) { }}

Now we get to importing our Project A.For that we need to do three things:

Add mavenLocal() as a repository.
Configure our java task to use the same or a newer toolchain version than Project A.
Add our project as a dependency

Note

Some parts that were already there were left out now.Only parts that were changed are shown.

repositories { mavenCentral() mavenLocal()}java { toolchain { languageVersion.set(JavaLanguageVersion.of(21)) }}dependencies { implementation("dev.chojo", "project-a", "1.0.0")}

Now we can go into our Project B class, create a new instance of our Project A class and call the meow method.

package dev.chojo.projectb;import dev.chojo.projecta.ProjectA;public class ProjectB { public static void main(String[] args) { new ProjectA().meow(); }}

If we run our main method now we can see that "meow" get printed out.

While this works in our IDE, it will not work when we actually build Project B and execute our Project B jar.

This has two reasons:

We did not define our main class anywhere.
Our IDE does imports Project A into our class path, since we imported it as implementation. When we build our IDE can no longer import it and gradle assumes that we will add Project A ourselves to the classpath. To fix this we can either use the shadow plugin or the application plugin. Configure either of them as described in the documentation

Note on minecraft plugins

When you are building a minecraft plugin there are several more things you should consider:

CompileOnly or Implementation

Whether your dependency is a compileOnly or implementation depends on multiple factos.

Implementation

The dependency is not a plugin
Is not hosted in maven central.
You are on an older version than 1.16.5

Make sure to use shadow and relocation

CompileOnly

The dependency is hosted on MavenCentral. Use the library loader
The dependency is another plugin. See next section

Depend or Softdepend

If your dependency is a plugin and imported as compileOnly make sure to add its name as a depend or soft-depend in your plugin.yml.

Soft-Depend

Your plugin can work without any class of your dependency

Depend

Your plugin will not work without the dependency.

Remote Repositories

To allow everyone to build your project regardless of their local maven repository content you should deploy your code into a remove repository.

The most famous one might be Maven Central.However, publishing there is quite complex and nothing for beginners.The repository is also intended for projects with general usability for the public.

There are several different pieces of software for self-hosting repositories like sonatype nexus or reposilite.If you don't want to self-host, there are a some repositories out there that are open to the public.However, have in mind that all those repositories require your project to be open source

Eldonexus hosted by me. (Reach out via discord, to apply for a namespace)
CodeMC

However, in the end publishing to a remote repository works similar.

All you need to do usually is to configure some simple auth:

publishing { publications { create<MavenPublication>("maven") { from(components["java"]) } } repositories { maven { name = "Example" authentication { credentials(PasswordCredentials::class) { username = "username" password = "password" } } url = uri("https://repo.example.com") } }}

Warning

Don't put your credentials in your code.Read them from some environment variable instead.

Once you configured your repository you have a new tasks called publishMavenPublicationToExampleRepository which allows you to publish to your remote repository.

Note

The task name changes based on the name you assign to your repository.

And that's it.Of course there is more to consider like snapshot and stable repositories. Plugins like publishData or indra can take care of that for example.

Thank you

That's it. Now you can easily share code between your projects or allow others to use code from your projects.

Thanks for reading!If you liked this post, or have some questions, feel free to come by my discord and have a chat!

Or write me a mail at mail [at] chojo [dot] dev.

If you want to support me, feel free to sponsor me via GitHub.

Jackson Bukkit - Bukkit serialization done the right way

chojo — Sat, 26 Aug 2023 10:57:22 +0200

Jackson Bukkit - Bukkit serialization done the right way

German Version

With the introduction of paper plugins, paper decided to drop support for the ConfigurationSerializable interface.While this interface and the system behind it provided a usable way to de/serialise an object fairly easily, it wasn't ideal by any means.It was hard to learn and required a lot of boilerplate code to simply de/serialise an object.So we're going to say goodbye to it. It won't be missed.

But now we need another system to serialise Bukkit objects and our configuration in general.A big advantage of the built-in interface was that it could serialise bukkit objects like Location or ItemStack out of the box.So we needed something similar.For this we will use jackson with one (or two) of my libraries that I maintain.

What is de/serialization

To get you where you are, we should probably take a look at what we are actually talking about.De/serialisation is the process of mapping objects in a programming language into a data format.This data format is usually text for human-readable data, or binary for machine-readable data.You may have heard of them.They have names like yaml, json, xml, toml or properties and many more.

So while our class might look like this:

public class Person { String name; int age; Address address; public static class Address { String street; String city; }}

It would look like this in various textual representations:

yamljsontomlxmlproperties

firstName: "Lilly"secondName: "Tempest"age: 21address: street: "Best street 1337" city: "Moonlight City"

{ "firstName" : "Lilly", "secondName" : "Tempest", "age" : 21, "address" : { "street" : "Best street 1337", "city" : "Moonlight City" }}

firstName = 'Lilly'secondName = 'Tempest'age = 21address.street = 'Best street 1337'address.city = 'Moonlight City'

<Person> <firstName>Lilly</firstName> <secondName>Tempest</secondName> <age>21</age> <address> <street>Best street 1337</street> <city>Moonlight City</city> </address></Person>

firstName=LillysecondName=Tempestage=21address.street=Best street 1337address.city=Moonlight City

The possibilities

Of course the market is huge in terms of serialization frameworks.To list a few:

SnakeYAML
The framework currently used by bukkit.Probably the most popular solution for pure yaml (I don't understand why).It also does only support yaml
Configurate
Developed by the sponge developers it is used by a wide variety of especially minecraft projects like Paper.Supports JSON, HOCON, YAML and XML.However, it uses several other libraries like jackson under the hood.
Jackson
Jackson is probably the most enterprise solution for serialization we have.It supports various dataformats throught a ton of different data format modules.The examples above are all created with jackson
GSON
Gson is the library most know for json.It is bundled in spigot and paper and used for a ton of applications there.Like the name says it only support JSON

I settled for jackson since it is the most flexible framework, widely used and has actually great documentation.

Obtaining jackson bukkit

Jackson bukkit is located in Maven Central. You can import it into your project with gradle or maven.

gradlemaven

dependencies { // Spigot server implementation("de.eldoria.jacksonbukkit", "bukkit", "2.0.0") // Paper server implementation("de.eldoria.jacksonbukkit", "paper", "2.0.0")}

<dependencies> <!-- Spigot Server --> <dependency> <groupId>de.eldoria.jacksonbukkit</groupId> <artifactId>spigot</artifactId> <version>2.0.0</version> </dependency> <!-- Paper Server--> <dependency> <groupId>de.eldoria.jacksonbukkit</groupId> <artifactId>paper</artifactId> <version>2.0.0</version> </dependency></dependencies>

Note

Please only use the module you need depending on your server version

Module Creation

You can either build the JacksonBukkit and JacksonPaper modules directly, or use the builder for easy modification.Use of the builder is recommended.The builder for bukkit and paper can both be accessed via the corresponding class.

Creating a Spigot ModuleCreating a Paper Module

ObjectMapper JSON = JsonMapper.builder() .addModule(JacksonBukkit.builder().build()) .build();

ObjectMapper JSON = JsonMapper.builder() .addModule(JacksonPaper.builder().build()) .build();

Of course you can also use TOML or YAML or whatever else Jackson supports.

The module builder also has more configuration options, which can be found here.

Difference between Paper and Bukkit module

The paper module tries to support all the features available in paper.The deserialiser will automatically detect the current format when using a legacy format and convert it to the new format when saving.Therefore, a config created on 1.15 will contain the legacy map, and once the server is running on 1.16, the byte array will be used instead.

Paper serialises ItemStack to a base64 encoded byte array instead of using spigots serialisation.This will only work on paper servers on 1.16 or later, not on spigot servers.The builder allows you to use spigots serialisation on paper servers, but this is not recommended.

When building a paper plugin the JacksonBukkit module is no longer able to serialise ItemStacks.You will need to use JacksonPaper in this case, and make sure you are not using legacy serialisation.

Class	Paper	Spigot
Color	RGB or HEX RGB < 1.19 <= RGBA or HEX RGBA	RGB or HEX RGB
ItemStack	legacy Map < 1.16 <= NBT byte array	Legacy Map
Component	MiniMessage String when MiniMessages is present. Otherwise Json Object.	Nope c:

In general, all classes that implement or have implemented the `ConfigurationSerializable' interface are supported.A complete list of supported classes can be found here.

Creating your first configuration file

We want to store player homes for our first config file.To do this, we create a base class called Homes, which holds a map of PlayerHomes with one entry per player.

Homes

public class Homes { private final Map<UUID, PlayerHomes> playerHomes; @JsonCreator public Homes(@JsonProperty("playerHomes") Map<UUID, PlayerHomes> playerHomes) { this.playerHomes = playerHomes; } public Homes() { this(new HashMap<>()); } public PlayerHomes get(UUID key) { return playerHomes.computeIfAbsent(key, k -> new PlayerHomes()); }}

The PlayerHomes class is the same just with a map containing the names of the homes.

PlayerHomes

public class PlayerHomes { private final Map<String, Location> homes; @JsonCreator public PlayerHomes(@JsonProperty("homes") Map<String, Location> homes) { this.homes = homes; } public PlayerHomes() { this(new HashMap<>()); } /** * Retrieves the location associated with the given name. * * @param name the name of the home. Case-insensitive * @return the location associated with the given name, or null if the name is not found */ @Nullable public Location get(String name) { return homes.get(name.toLowerCase()); } /** * Puts a new entry in the homes map with the specified name and location. * * @param name the name of the entry. Will be converted to lower case * @param location the location associated with the entry */ public void put(String name, Location location) { homes.put(name.toLowerCase(), location); }}

Let's take a look at what we've done here.

We have created two classes that contain the information we need and added some utility methods to get the houses and register new houses.

The most important part is our constructor, which is used to create our instances when we read our configuration file.These are the constructors annotated with @JsonCreator.These classes will be used by jackson.After that, we just need to annotate the input fields with their corresponding names using the @JsonProperty annotation.

That's all we need to do.

Creating our ObjectMapper

As mentioned earlier, Jackson uses object mapper to map objects from and to our dataformat.Since we want to continue using yaml, we need to import the yaml dataformat.The latest version is shown above.

gradlemaven

dependencies { implementation("com.fasterxml.jackson.dataformat", "jackson-dataformat-yaml", "2.21.3")}

<dependencies> <dependency> <groupId>com.fasterxml.jackson.dataformat</groupId> <artifactId>jackson-dataformat-yaml</artifactId> <version>2.21.3</version> </dependency></dependencies>

Once we imported the yaml dataformat we can use it to create an object mapper and configure it.

ObjectMapper mapper = YAMLMapper.builder().addModule(JacksonPaper.builder().build()) .build() .setVisibility(PropertyAccessor.FIELD, JsonAutoDetect.Visibility.ANY) .setVisibility(PropertyAccessor.GETTER, JsonAutoDetect.Visibility.NONE);

We also configure the mapper to use the fields in our classes and ignore the get prefixed methods.This saves us some time and is what you usually want. If you want to exclude a field in your class from being written, you can add the @JsonIgnore annotation to it.

Writing our config file

Once you added some data to your homes object we need to write it into a file.For that we will use the ObjectMapper we created above and will use it to write it to a file in our plugins directory.

Note

I created some sample data here after creating my homes instance.

ObjectMapper mapper = YAMLMapper.builder().addModule(JacksonPaper.builder().build()) .build() .setVisibility(PropertyAccessor.FIELD, JsonAutoDetect.Visibility.ANY) .setVisibility(PropertyAccessor.GETTER, JsonAutoDetect.Visibility.NONE);Homes homes = new Homes();mapper.writeValue(plugin.getDataFolder().toPath().resolve("homes.yml").toFile(), homes);

Warning

Handle the IOException properly

Note

You should cache your ObjectMapper and reuse it instead of creating it again on every usage.

And now we have written our homes object as a yaml file directly to disk.

Our config file looks something like this:

homes.yml

---playerHomes: "5c4a58ce-2c5e-417e-9022-328489126845": homes: home: uid: "f3a41fe9-64b0-45ee-948e-a29ce4a92b15" name: "world" xCoord: -98.0 yCoord: 54.0 zCoord: 54.0 yaw: 59.0 pitch: 300.0 "333bea57-90f2-4f62-a9a4-911294c79d77": homes: home: uid: "f3a41fe9-64b0-45ee-948e-a29ce4a92b15" name: "world" xCoord: -55.0 yCoord: -46.0 zCoord: 72.0 yaw: 301.0 pitch: 189.0 ff88dace-9ef3-47a6-9c70-d93ddcf781f2: homes: another_home: uid: "f3a41fe9-64b0-45ee-948e-a29ce4a92b15" name: "world" xCoord: 50.0 yCoord: -99.0 zCoord: -55.0 yaw: 19.0 pitch: 154.0 my_home: uid: "f3a41fe9-64b0-45ee-948e-a29ce4a92b15" name: "world" xCoord: 97.0 yCoord: -66.0 zCoord: -4.0 yaw: 20.0 pitch: 167.0

You can see that the location has been automatically broken down into a nice readable format.Worlds are stored with their uid and name for readability.

Reading our configuration file

Reading the configuration file is as simple as writing it.

ObjectMapper mapper = YAMLMapper.builder().addModule(JacksonPaper.builder().build()) .build() .setVisibility(PropertyAccessor.FIELD, JsonAutoDetect.Visibility.ANY) .setVisibility(PropertyAccessor.GETTER, JsonAutoDetect.Visibility.NONE);Homes homes = mapper.readValue(plugin.getDataFolder().toPath().resolve("homes.yml").toFile(), Homes.class);

If the file doesn't exist it will fail, so you might want to add an existence check and create an empty config file:

File homesFile = plugin.getDataFolder().toPath().resolve("homes.yml").toFile();if (!homesFile.exists()) mapper.writeValue(homesFile, new Homes());Homes homes = mapper.readValue(homesFile, Homes.class);

Using a config wrapper for configuration files

Of course, this can all be done much more easily.I have written a wrapper that allows easy handling of configuration files with jackson.

It is also available in Maven Central and can be imported with maven or gradle:

gradlemaven

dependencies { implementation("de.eldoria.jacksonbukkit", "jackson-configuration", "2.1.11")}

<dependencies> <dependency> <groupId>de.eldoria.jacksonbukkit</groupId> <artifactId>jackson-configuration</artifactId> <version>2.1.11</version> </dependency></dependencies>

The jackson configuration wrapper is designed to handle multiple files, with one file set as the default, aka main configuration file.Configuration files are defined using ConfigKeys which provide a human readable name, path to the file and also a default value for the class.

The config key for our homes file would look like this ConfigKey.of("homes", Path.of("homes.yml"), Homes.class, Homes::new).First we define the human readable name, which is homes, followed by the path within the plugin directory.Then we pass the class and a default value if the file doesn't exist yet.

The default key for the config.yml can be created a bit easier with ConfigKey.defaultConfig(Configuration.class, Configuration::new).

The quickest way to access our files is to simply create an instance of JacksonConfig and pass it our homes file as the default configuration.

// Create the config key for our homes fileConfigKey<Homes> homesKey = ConfigKey.of("homes", Path.of("homes.yml"), Homes.class, Homes::new);// Create a new instance and set the homes.yml as main configurationJacksonConfig<Homes> config = new JacksonConfig<>(plugin, homesKey);// Get the instance of our main configurationHomes main = config.main();// make some changes// Save all configuration filesconfig.save();// Only save the configuration with that key.config.save(homesKey);

The library takes care of the creation of our file and also allows us to easily save and retrieve it.

To load other files you just need to create a new ConfigKey and call JacksonConfig#secondary(ConfigKey) with it.

However, the nicer way is to create your own class based on the JacksonConfig class.You can also add a config.yml and use that as the main configuration and your homes file as the secondary configuration.

public class Configuration extends JacksonConfig<General> { private static final ConfigKey<General> MAIN = ConfigKey.defaultConfig(General.class, General::new); private static final ConfigKey<Homes> HOMES = ConfigKey.of("homes", Path.of("homes.yml"), Homes.class, Homes::new); public Configuration(@NotNull Plugin plugin) { super(plugin, MAIN); } public Homes homes() { return secondary(HOMES); } public Wrapper<Homes> homesWrapped() { return secondaryWrapped(HOMES); }}

And that's it.You can now use your Configuration instance to access your main plugin.yml and also access your homes file via the custom method.

// Create a new configuration instanceConfiguration configuration = new Configuration(plugin);// Get the main configuration fileGeneral general = configuration.main();// Get the homes configuration fileHomes homes = configuration.homes();// Add a home to the playerhomes.get(player).put("home", location);// save all filesconfiguration.save();// Use the wrapper to automatically save once the wrapper is closedtry (var temp = configuration.homesWrapped()) { // Add a home to the player temp.config().get(player).put("home", location);}

The wrapped method allows you to get the config wrapper into an auto closable, which will automatically save the file once the block is left.

Migrating from ConfigurationSerializable

If you have used bukkit serialisation before, it is quite easy to use your new objects.All you need to do is mark your constructor as the json creator and remove the old map constructor.Of course, make sure that your users have already migrated before you remove the constructor completely from your project c:

-public final class PersonCS implements ConfigurationSerializable {+public final class PersonCS {  private final String firstName;  private final String secondName;  private final int age;  private final Address address;- public PersonCS(Map<String, Object> map) {- firstName = (String) map.get("firstName");- secondName = (String) map.get("secondName");- age = (Integer) map.get("age");- address = (Address) map.get("address");- }+ @JsonCreator+ public PersonCS(@JsonProperty("firstName") String firstName,+ @JsonProperty("secondName") String secondName,+ @JsonProperty("age") int age,+ @JsonProperty("address") Address address) {  this.firstName = firstName;  this.secondName = secondName;  this.age = age;  this.address = address;  }- @Override- public @NotNull Map<String, Object> serialize() {- HashMap<String, Object> map = new HashMap<>();- map.put("firstName", firstName);- map.put("secondName", secondName);- map.put("age", age);- map.put("address", address);- return map;- }  /* GETTER */  public static final class Address implements ConfigurationSerializable {  private final String street;  private final String city;- public Address(Map<String, Object> map) {- street = (String) map.get("street");- city = (String) map.get("city");- }+ @JsonCreator+ public Address(@JsonProperty("street") String street,+ @JsonProperty("city") String city) {  this.street = street;  this.city = city;  }- @Override- @NotNull- public Map<String, Object> serialize() {- HashMap<String, Object> map = new HashMap<>();- map.put("street", street);- map.put("city", city);- return map;- }  /* GETTER */  } }

Instead of creating a constructor for your classes, you can also use the fields to map values.I just prefer constructors because they are less hacky than reflection stuff.

Thank you!

Thank you for sticking with me so far.You can now easily create configuration files with jackson and use them in your plugins!

Thanks for reading!If you liked this post, or have some questions, feel free to come by my discord and have a chat!

Or write me a mail at mail [at] chojo [dot] dev.

If you want to support me, feel free to sponsor me via GitHub.

Logging in Minecraft - The good and better way

chojo — Thu, 10 Aug 2023 15:11:20 +0200

Logging in Minecraft - The good and better way

German Version

This blog post is about logging and writing information to the console in Minecraft.There are a lot of ways to write data to the Minecraft console.And there are a lot of bad or wrong ways to write to the Minecraft console.We'll start by looking at some bad practices, then move on to the built-in plugin logger, and finish with a look at slf4j.

The five types of logging

As mentioned earlier, there are several ways (at least five) to write to the console.Let's have a look at them before I explain them.

public final class MyPlugin extends JavaPlugin { private static final Logger log = LoggerFactory.getLogger(MyPlugin.class); @Override public void onEnable() { System.out.println("Writing via std out"); Bukkit.getConsoleSender().sendMessage("Writing via console sender"); Bukkit.getLogger().info("Writing via bukkit logger"); getLogger().info("Writing via plugin logger"); log.info("Writing via slf4j logger"); }}

This results in these outputs:

[15:39:35 INFO]: [MyPlugin] [STDOUT] Writing via std out[15:39:35 WARN]: Nag author(s): '[]' of 'MyPlugin v1.0.0' about their usage of System.out/err.print. Please use your plugin's logger instead (JavaPlugin#getLogger).[15:39:35 INFO]: Writing via console sender[15:39:35 INFO]: Writing via bukkit logger[15:39:35 INFO]: [MyPlugin] Writing via plugin logger[15:39:35 INFO]: [dev.chojo.myplugin.MyPlugin] Writing via slf4j logger

You may have already noticed some important differences, but let us take a closer look.

Don'ts

All logging methods in this section are don'ts.If you are only interested in how to do it properly, jump directly to dos

Standard output

Don't do this!

While System.out.println is a valid use case when you need a quick response from your application, there are often much better ways.In general, it should always be avoided.It is probably the worst way if you are using Spigot, and still a bad way if you are using Paper.Paper captures everything a plugin writes to std and actually uses the plugin logger to write it.This way the reader actually knows where the print came from.This is not the case when using Spigot.People will just end up with a printout like when using the console sender or bukkit logger method.You don't know where it came from.

If you use the default out to write, you will also get a nice message on Paper servers:

[15:39:35 INFO]: [MyPlugin] [STDOUT] Writing via std out[15:39:35 WARN]: Nag author(s): '[]' of 'MyPlugin v1.0.0' about their usage of System.out/err.print. Please use your plugin's logger instead (JavaPlugin#getLogger).

It already suggests something else, the plugin logger, which we will look at later.

Console sender

Don't do this!

The console sender is just as bad as standard output, except that it doesn't really tell you where the message came from.All you get is a simple text with some message that you may or may not understand.

[15:39:35 INFO]: Writing via console sender

Bukkit Logger

Don't do this!

While the bukkit logger is actually a logger and can be used as such, it still lacks the information about which plugin sent the message.The only advantage it has is that it can log exceptions properly.Other than that, it is still as bad as the console sender and standard out methods.

[15:39:35 INFO]: Writing via bukkit logger

Do's

These are the ways to go if you want to write something to the console.

Plugin Logger

The Plugin' class provides a method called#getLogger()`.This method returns a Logger which allows you to write at different levels and also log exceptions properly.It also adds the name of your plugin to the top of your log message, so everyone can easily see which plugin sent the message.

To write on different levels you can use these methods:

Logger#info(String)
Logger#warning(String)
Logger#severe(String)

There are more levels like config, fine, finer and finest, but if you're using Paper or Spigot, these messages won't appear in your console or log file.There are workarounds, such as implementing a custom logger that simply delegates to the info level instead, or using reflections to change the logger configuration, but that is beyond the scope of this post.

If you are using the logger, it looks like this:

getLogger().info("This is a info");getLogger().warning("This is a warning");getLogger().severe("This is an error");

[16:13:08 INFO]: [MyPlugin] This is a info[16:13:08 WARN]: [MyPlugin] This is a warning[16:13:08 ERROR]: [MyPlugin] This is an error

Logging exceptions

While in most cases it may be sufficient to simply write messages, we will probably want to log exceptions at some point.

You may have seen this in many cases:

try { throw new RuntimeException("This is not good");} catch (Exception e) { e.printStackTrace();}

Output

[16:13:08 WARN]: java.lang.RuntimeException: This is not good[16:13:08 WARN]: at myplugin-1.0.0.jar//dev.chojo.myplugin.MyPlugin.onEnable(MyPlugin.java:25)[16:13:08 WARN]: at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:281)[16:13:08 WARN]: at io.papermc.paper.plugin.manager.PaperPluginInstanceManager.enablePlugin(PaperPluginInstanceManager.java:189)[16:13:08 WARN]: at io.papermc.paper.plugin.manager.PaperPluginManagerImpl.enablePlugin(PaperPluginManagerImpl.java:104)[16:13:08 WARN]: at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:507)[16:13:08 WARN]: at org.bukkit.craftbukkit.v1_20_R1.CraftServer.enablePlugin(CraftServer.java:640)[16:13:08 WARN]: at org.bukkit.craftbukkit.v1_20_R1.CraftServer.enablePlugins(CraftServer.java:551)[16:13:08 WARN]: at net.minecraft.server.MinecraftServer.loadWorld0(MinecraftServer.java:636)[16:13:08 WARN]: at net.minecraft.server.MinecraftServer.loadLevel(MinecraftServer.java:435)[16:13:08 WARN]: at net.minecraft.server.dedicated.DedicatedServer.e(DedicatedServer.java:308)[16:13:08 WARN]: at net.minecraft.server.MinecraftServer.w(MinecraftServer.java:1101)[16:13:08 WARN]: at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:318)[16:13:08 WARN]: at java.base/java.lang.Thread.run(Thread.java:833)

This is bad, don't do it!

Instead, you need to use the #log(Level, String, Throwable) method of your logger.

try { throw new RuntimeException("This is not good");} catch (Exception e) { getLogger().log(Level.SEVERE, "Something went wrong", e);}

The Level class is a built-in Java class that is part of the java.util.logging package.Calling this method will print your exception nicely, containing a message, the exception message and a stack trace.

Warning

If you cannot make sense of this, I recommend reading this stackoverflow post

[16:10:43 ERROR]: [MyPlugin] Something went wrongjava.lang.RuntimeException: This is not good at dev.chojo.myplugin.MyPlugin.onEnable(MyPlugin.java:25) ~[myplugin-1.0.0.jar:?] at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:281) ~[paper-api-1.20.1-R0.1-SNAPSHOT.jar:?] at io.papermc.paper.plugin.manager.PaperPluginInstanceManager.enablePlugin(PaperPluginInstanceManager.java:189) ~[paper-1.20.1.jar:git-Paper-117] at io.papermc.paper.plugin.manager.PaperPluginManagerImpl.enablePlugin(PaperPluginManagerImpl.java:104) ~[paper-1.20.1.jar:git-Paper-117] at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:507) ~[paper-api-1.20.1-R0.1-SNAPSHOT.jar:?] at org.bukkit.craftbukkit.v1_20_R1.CraftServer.enablePlugin(CraftServer.java:640) ~[paper-1.20.1.jar:git-Paper-117] at org.bukkit.craftbukkit.v1_20_R1.CraftServer.enablePlugins(CraftServer.java:551) ~[paper-1.20.1.jar:git-Paper-117] at net.minecraft.server.MinecraftServer.loadWorld0(MinecraftServer.java:636) ~[paper-1.20.1.jar:git-Paper-117] at net.minecraft.server.MinecraftServer.loadLevel(MinecraftServer.java:435) ~[paper-1.20.1.jar:git-Paper-117] at net.minecraft.server.dedicated.DedicatedServer.initServer(DedicatedServer.java:308) ~[paper-1.20.1.jar:git-Paper-117] at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1101) ~[paper-1.20.1.jar:git-Paper-117] at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:318) ~[paper-1.20.1.jar:git-Paper-117] at java.lang.Thread.run(Thread.java:833) ~[?:?]

The SLF4J logger

Internally, Paper and Spigot uses a framework called slf4j with an implementation called log4j.Even if you use the plugin logger, you are still using the slf4j framework.So you can actually use it directly.Instead of prefixing your message with the plugin name, the slf4j logger will prefix your output with the class name that is sending the message.This gives you even more detail about where the message is coming from.

Aside from its practical use in Minecraft, slf4j is also widely used in other projects, and you will encounter it very often outside the Minecraft world.This makes it generally good to know if you are going to go out and work with other frameworks and libraries.

To get a logger instance for your class, you need the LoggerFactory class, call the #getLogger(Class) method and pass your current class.As this is some lame manual work, you can simply create a live template for it if you are using IntelliJ.

The live template looks like this (an import template is in the spoiler below):

private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger($class$.class);

XML Template for import

To import this, create a new Java Live template, copy the XML code above and paste it into your newly created template.

<template name="log" value="private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger($class$.class);" description="insert a default logger" toReformat="false" toShortenFQNames="true" useStaticImport="true"> <variable name="class" expression="className()" defaultValue="className()" alwaysStopAt="false" /> <context> <option name="JAVA_DECLARATION" value="true" /> </context></template>

If you register this with the abbreviation log, all you have to do is type log in your class and the logger will be inserted.You will end up with something like this:

private static final Logger log = LoggerFactory.getLogger(MyPlugin.class);

Using this logger instance is very similar to using the plugin logger, but there are some differences.

Let's look at basic logging first.

log.info("This is a info");log.warn("This is a warning");log.error("This is an error");

[16:32:03 INFO]: [dev.chojo.myplugin.MyPlugin] This is a info[16:32:03 WARN]: [dev.chojo.myplugin.MyPlugin] This is a warning[16:32:03 ERROR]: [dev.chojo.myplugin.MyPlugin] This is an error

You can see that we now have the plugin class as a prefix to our message.Instead of warning we now use warn and instead of severe we use error.

Logging exceptions

Logging exceptions is easier with slf4j.All we need to do is pass it as a second argument after our message.

try { throw new RuntimeException("This is not good");} catch (Exception e) { log.error("Something went wrong", e);}

The output remains the same as with plugin logger, except that we now have the class prefix again.

Output

[16:34:49 ERROR]: [dev.chojo.myplugin.MyPlugin] Something went wrongjava.lang.RuntimeException: This is not good at dev.chojo.myplugin.MyPlugin.onEnable(MyPlugin.java:40) ~[myplugin-1.0.0.jar:?] at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:281) ~[paper-api-1.20.1-R0.1-SNAPSHOT.jar:?] at io.papermc.paper.plugin.manager.PaperPluginInstanceManager.enablePlugin(PaperPluginInstanceManager.java:189) ~[paper-1.20.1.jar:git-Paper-117] at io.papermc.paper.plugin.manager.PaperPluginManagerImpl.enablePlugin(PaperPluginManagerImpl.java:104) ~[paper-1.20.1.jar:git-Paper-117] at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:507) ~[paper-api-1.20.1-R0.1-SNAPSHOT.jar:?] at org.bukkit.craftbukkit.v1_20_R1.CraftServer.enablePlugin(CraftServer.java:640) ~[paper-1.20.1.jar:git-Paper-117] at org.bukkit.craftbukkit.v1_20_R1.CraftServer.enablePlugins(CraftServer.java:551) ~[paper-1.20.1.jar:git-Paper-117] at net.minecraft.server.MinecraftServer.loadWorld0(MinecraftServer.java:636) ~[paper-1.20.1.jar:git-Paper-117] at net.minecraft.server.MinecraftServer.loadLevel(MinecraftServer.java:435) ~[paper-1.20.1.jar:git-Paper-117] at net.minecraft.server.dedicated.DedicatedServer.initServer(DedicatedServer.java:308) ~[paper-1.20.1.jar:git-Paper-117] at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1101) ~[paper-1.20.1.jar:git-Paper-117] at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:318) ~[paper-1.20.1.jar:git-Paper-117] at java.lang.Thread.run(Thread.java:833) ~[?:?]

Using placeholders in messages

slf4j has a nice feature for placeholders.To add additional information to your message, you can define placeholders with {} and pass the values after your message in the correct order.

log.info("Hello {}. How was your {}? Is it already past {}?", "Chojo", "day", 2);

[16:39:49 INFO]: [dev.chojo.myplugin.MyPlugin] Hello Chojo. How was your day? Is it already past 2?

You can see that the values are simply inserted into your message.

This also works with exceptions.Just make sure that your last argument is the exception itself, and that any replacements are specified first.

var first = 5;var second = 0;try { var result = first / second;} catch (Exception e) { log.error("I tried to divide {} through {} and it went up in flames", first, second, e);}

[16:39:49 ERROR]: [dev.chojo.myplugin.MyPlugin] I tried to divide 5 through 0 and it went up in flamesjava.lang.ArithmeticException: / by zero at dev.chojo.myplugin.MyPlugin.onEnable(MyPlugin.java:51) ~[myplugin-1.0.0.jar:?] at ... #Shortened by me

Works like a charm and makes it very easy to add extra information to your output message!

Adding a prefix

While adding a prefix when using any of the methods in the don't section might help a bit, it's still bad.Why use a bad way when there are good ways.

Thank you!

Now you know how to log into your Minecraft project properly!

Thanks for reading!If you liked this post, or have some questions, feel free to come by my discord and have a chat!

Or write me a mail at mail [at] chojo [dot] dev.

If you want to support me, feel free to sponsor me via GitHub.

Redirecting to an external domain with traefik

chojo — Sat, 05 Aug 2023 10:38:40 +0200

Redirecting to an external domain with traefik

German Version

Welcome to another blog post!This time we will look at how to redirect to an external url using traefik without using a container.Docker is completely optional, but I run my traefik with docker, so I will refer to that as well.This should also work with others, but I have not tested or done so yet.

Setting up the file provider

To inject our redirects into traefik we will use the file provider.To do this we need to do two things

Create a file provider directory

Create a new directory provider next to your compose file and mount it into your container.

 volumes: - "./provider/:/provider/"

Enabling the file provider in the configuration

Now we need to modify our traefik.yaml and add a file provider.

providers: file: directory: "/provider/" watch: true

This will make traefik watch every file in our provider directory.This allows us to use multiple files to group our providers and keep them more organised.Traefik will also watch for changes to our providers, so as soon as we edit, create or delete a file, those changes will instantly affect traefik's routing.

Warning

Traefik only monitors files in the root directory, so you cannot use subdirectories.

Warning

Do not forget to restart your traefik container.

Creating a redirect

To create a redirect we need two things, a redirectRegex middleware and a router to accept the requests.For this we will create a file redirect.yml (the name can be anything) in our new provider directory.

Note

Alternatively you can create one file for each redirect.A shell script for this can be found below

Setting up the redirectRegex middleware

http: middlewares: # (1)! chojo-dev-redirect: # (2)! redirectRegex: # (3)! regex: "(.*)" # (4)! replacement: "https://chojo.dev/" # (5)! permanent: false # (6)!

We create middlewares, so we use the middleware section.
Define a new middleware with the name chojo-dev-redirect.
Define the type of the middleware as redirectRegex.
Define the regex pattern as (.*), which will basically match anything. This is the part of the url we want to replace.So we really want to replace all of the string.
Define the new url we want to redirect to.
Mark the redirect as temporary.This will prevent the browser from caching, and changes to our redirect will take effect immediately.

If you want to know what each line does, look at the comments.

Setting up the router

Every router needs a service to which it is connected.Of course, we could use Docker to start a service for each of our redirections, or we could start a single service and reuse it.Luckily traefik already has us covered and offers a service for exactly this use case called noop@internal.

Note

The middlewares section is still there, I'm just not showing it.

http: routers: # (1)! chojo-dev-redirect: # (2)! service: noop@internal # (3)! entrypoints: "https" # (4)! rule: "Host(`my.host.com`)" # (5)! middlewares: "chojo-dev-redirect" # (6)! tls: certresolver: my_cert_resolver # (7)!

We are going to create a router, so we will use the routers section.
Define a new router called chojo-dev-redirect. I recommend using the same name as the middleware, but it is not required.
Add the noop@internal service to our router.
Assign the https entrypoint. This may vary depending on your setup.
Assign the rule to our host
Assign the redirect middleware we defined earlier
Assign our cert resolver to the assigned rule

Warning

Make sure you adapt entrypoint, rule and certresolver to your needs!

This will create our service.Anything matching our rule will now be redirected to the domain defined in the redirect middleware.

Using a shell script to create redirects.

I use a bash script to create my redirects.

Script

#!/usr/bin/env shread -rp "Enter the name for the router and middleware: " NAMEif [ -z "$NAME" ]; then echo "Name cannot be empty. Exiting..." exit 1firead -rp "Enter the target URL you want to redirect to: " TARGETif [ -z "$TARGET" ]; then echo "Target URL cannot be empty. Exiting..." exit 1firead -rp "Enter the host that should be redirected: " HOSTif [ -z "$HOST" ]; then echo "Host cannot be empty. Exiting..." exit 1firead -rp "Enter the cert resolver: " CERTif [ -z "$CERT" ]; then echo "Cert resolver cannot be empty. Exiting..." exit 1firead -rp "Do you want the redirection to be permanent? [y/N]: " PERMANENT_INPUTPERMANENT_INPUT=${PERMANENT_INPUT:-n}PERMANENT=falseif [ "${PERMANENT_INPUT}" = "y" ] || [ "${PERMANENT_INPUT}" = "Y" ]; then PERMANENT=trueelif [ "${PERMANENT_INPUT}" != "n" ] && [ "${PERMANENT_INPUT}" != "N" ]; then echo "Invalid input for permanent value." exit 1fiTEXT="http: middlewares: ${NAME}-redirect: redirectRegex: regex: \"(.*)\" replacement: \"${TARGET}\" permanent: ${PERMANENT} routers: ${NAME}-redirect: service: noop@internal entrypoints: \"https\" rule: \"Host(\`${HOST}\`)\" middlewares: \"${NAME}-redirect\" tls: certresolver: ${CERT}"echo "$TEXT" > "${NAME}-redirect.yml"echo "$TEXT"echo "File ${NAME}-redirect.yml created."

You can get it with

wget https://chojo.dev/assets/files/redirect.sh && chmod +x redirect.sh

Warning

Never run a bash script without looking at them!

The bash script creates a file for each redirect.This makes them easy to find.If you want to change it, just create it again with the same name.

Thank you

Thanks for reading!If you liked this post, or have some questions, feel free to come by my discord and have a chat!

Or write me a mail at mail [at] chojo [dot] dev.

If you want to support me, feel free to sponsor me via GitHub.

Minecraft Development with Gradle: Basic and Advanced | A guide

chojo — Fri, 04 Aug 2023 13:04:03 +0200

Minecraft Development with Gradle: Basic and Advanced | A guide

German Version

This blog post is about developing Minecraft plugins for Paper and Spigot servers using Gradle.The Minecraft community has built a huge ecosystem for Minecraft around the Gradle build tool.Instead of throwing a sample Gradle file at you, we will go through this step by step.We will start with the basic Gradle layout, set up repositories and dependencies, and move on to plugins.

What is Gradle?

Gradle is a project management system or build tool.It basically takes care of your build process, resolves dependencies, runs tests and can do all sorts of things, even start a Minecraft server.Gradle uses Kotlin or Groovy for the build file.I recommend using Kotlin.Where you need custom plugins in maven, you can simply write your own logic directly into the build file when using Gradle.But enough of examples, time to get started.

Install Gradle

If you haven't already installed Gradle, you should do so first.I will not go into detail on this as Gradle itself has great documentation on this.We will only use Gradle to initialise the project, and then use the Gradle wrapper.

The Gradle wrapper

The Gradle wrapper is essentially a portable Gradle installation.It does not require a Gradle installation on the system and can be used to build anywhere.This is why it has its own version.To update this version you only need one command:

./gradlew wrapper --gradle-version=9.5.1 --distribution-type=bin

This works on Unix systems as well as in Windows PowerShell or git bash.If you are using windows cmd, you will need to use gradlew.bat instead.

Check the Gradle website for the latest version.

Setting up a Gradle project

Using IntelliJUsing EclipseUsing CLI

We will look at the marks one after another. Most of the settings will be set by default already.

We select New Project
We add our project id aka name.
This name is your plugin name in lower case with - where a space would be.
So MyPlugin becomes my-plugin
Make sure that a git repository will be created
Select Java as language or Kotlin if you like this more, but I will only use Java here.
Select Gradle as build system
Select Kotlin as Gradle DSL
Let intellij add some sample code.
This will be removed later, but will create the most important directories.
Select the wrapper as your Gradle distribution
Enter the latest Gradle version, as mentioned on the Gradle website.
This may not be available to select in the drop down menu, but you can enter it yourself.
Enter your group id here.If you don't know what to write here have a log at my other postIf you don't have a domain, see here
This is the same as your name in 2.

Sorry Eclipse users.Time to use an actually good IDE.Switch to IntelliJ c:

If you already have a project, you can easily set it up from the command line.If your project is currently a Maven project, Gradle will offer to convert it to a Gradle project.

We will look at how to set up a new Gradle project without importing anything from Maven.

First we start by initialising Gradle with Gradle init.We're using the installed version of Gradle for this, so you need to have it installed.

You will end up with this dialogue

Select type of project to generate: 1: basic 2: application 3: library 4: Gradle pluginEnter selection (default: basic) [1..4]

Choose 1 here by simply typing 1, or just hit enter since basic is the default.This will create a basic Gradle project.

If you want to create a library instead, you can choose 3.However, all this does is to apply some basic plugins beforehand, which we will get through later anyway.

The next step is to select the language for our Gradle DSL

Select build script DSL: 1: Kotlin 2: GroovyEnter selection (default: Kotlin) [1..2]

Again, choose 1 by typing 1 or just hit enter since Kotlin is the default.

Now we need to enter our project name.I recommend using your plugin name in lower case and adding - where there would be spaces.So MyPlugin becomes my-plugin.

Project name (default: directory):

Next is a question about Gradle stuff.

Generate build using new APIs and behavior (some features may change in the next minor release)? (default: no) [yes, no]

I recommend using the default no. So just press enter or type no.And you're done.

Gradle files

Now you have a bunch of new files.Let's go through them one by one.

Gradle directory

The Gradle directory contains the wrapper directory, which in turn contains a `gradle-wrapper.jar', which is your Gradle wrapper.This is your portable Gradle installation as mentioned earlier.

The gradle-wrapper.properties contains the settings of the wrapper.The most important part is the version.You can also change it here if you forgot to use the command shown in the previous section.

build.gradle.kts

The build.gradle.kts is the heart of our project.Almost all the configuration of our project is done in this file.It contains dependencies, repositories and lots of other stuff.

gradlew and gradlew.bat

These are the Gradle wrapper files.

gradlew for Unix systems, Windows powershell and git bash on Windows.
gradlew.bat for the windows cmd

settings.gradle.kts

The settings can be used to apply project wide settings such as plugin repositories (not dependency repositories!).You can also define submodules here if you have a multi-module project, or create a version catalogue.

src directory

While this directory is not strictly seen as part of Gradle, it is still important to have a specific structure:

.└── src/ ├── main/ │ ├── java │ └── resources └── test/ ├── java └── resources

If these directories do not exist in your src directory, please create them.

The basic build.gradle.kts

Let's start by taking a look at our build.gradle.kts.It should be empty at the moment if you used the cli approach, or already have some stuff in it if you set it up using IntelliJ.

Let's get you on the same page by adding some sections to start with a fresh file.

The plugin section

The top section of our file will always be the `plugins' section.So we start by adding it first.

plugins {}

plugins { java}

And that's it. We are done with our plugin setup for now.

Declare group and version

group = "dev.chojo"version = "1.0.0-SNAPSHOT"

Repositories section

The repositories section is where we define which repositories our dependencies will be in.

We will most likely need two repositories.

mavenCentral()
This is the Maven Central repository where most of the dependencies we will need are located. If you have been using Maven: With Maven you did not need to import this specifically, but with Gradle you will need to do so.
maven("https://repo.papermc.io/repository/maven-public/")
This will import the paper-mc repository. Of course you can do the same with any other repository.

repositories { mavenCentral() maven("https://repo.papermc.io/repository/maven-public/")}

Order is important!

The order in which you assign repositories in this section is the order in which Gradle will search for dependencies.It will take the first found location where the dependency exists.

Maven local.

If you want to use dependencies from your local Maven repository, you need to add mavenLocal() at the top of the section.I strongly recommend doing this only for local development, as it destroys the ability to build on other machines.

Dependencies section

Note

If you have test imports from junit here, you can delete them for now.

Inside the dependencies section, we can define two different dependency types for now:

dependencies { compileOnly("io.papermc.paper:paper-api:26.1.2.build.63-stable") implementation("de.chojo.sadu", "sadu", "2.3.9")}

Note

SADU is here only for demonstration purposes and not mandatory required

I have used two different ways of declaring dependencies here.Both are valid.You can either declare them as one string or as three separate strings.

SADU is a library I wrote to make using databases easier for beginners. Have a look at it c:

As implementationAs compileOnly

The implementation imports are dependencies that are not part Paper, and therefore need to get into your plugin somehow.This will not work now, but we will fix this in a later step.

The compileOnly imports are dependencies that we only need to build our project, but are either not needed to run it, or are provided in some other way.This means that dependencies like Paper, FAWE, LuckPerms and in general any other api by other plugins will be imported as compileOnly.APIs that are not available as plugins on the server, which can be the case for Inventory APIs for example, must of course be imported as an implementation.

Tasks section

Note

You can delete anything currently in your tasks section

I told you earlier that everything in Gradle works with tasks.So there has to be a way to configure them, and this is where the tasks section comes in.For now we will just start with a simple empty section.

tasks {}

Configuring Java

Now that we have all the necessary sections in our file, we can finally start configuring our project.

The first thing we need to configure is the java plugin, which we have already imported.While I have shown you the basic sections, there are more, as almost every plugin adds its own section for configuration.This means that we can not only configure the tasks of our plugins, but also the plugin itself.

java { toolchain { languageVersion.set(JavaLanguageVersion.of(21)) } withSourcesJar() withJavadocJar()}

For java we set the so-called toolchain.The toolchain controls the version of java used in our project.If you want to import a dependency compiled with java 17, you need to set your toolchain to 17 as well.On the other hand, using a java 17 toolchain will still allow you to import any dependency using an older version of java.

We also define that we want to build a source jar and a javadoc jar.This may not be important to us now, but it may be in the future.It doesn't hurt to have it in the end.

In addition to configuring our java plugin, we also want to configure its tasks.There are three tasks of interest to us:

compileJavacompileJavaTestjavadoc

This task is responsible for compiling our Java code.

This task handles the compilation of our test code written in Java.Although we do not have any tests yet, it cannot hurt to define them anyway.

This handles how our javadocs are built.

All we want to define for these tasks is that we want to use UTF-8 encoding for them.This will avoid weird characters when using special characters.

tasks { compileJava { options.encoding = "UTF-8" } compileTestJava { options.encoding = "UTF-8" } javadoc { options.encoding = "UTF-8" }}

And that's the configuration for our Java plugin.

Building the plugin

There is nothing stopping us from building our plugin now.All we need is a plugin.yml.While we could stop here and just be happy that it works, there is still a lot (and by that I mean A LOT) of room for improvement.We also still have to fix the problem of not including our library that we previously imported with implementation.So while you might be tempted to call it a day, I highly recommend you keep reading!

For now, I will just show you the two ways to run a Gradle task.

Note

You can run not only the build task with this, but any other task as well.If you are using IntelliJ you can have a look at the other tasks that are available.

Via cliVia IntelliJ

Go into your cli and run ./gradlew build' orgradlew.bat build' depending on your operating system.

Open the Gradle window on the right. Go to Tasks -> Build and run the build task by clicking on it.

Getting the build file

You will now find your plugin in build/libs/myplugin.jar.This is not on your server yet of course, but we have a very easy way to get it.

Copy a jar after build

Warning

Instead of doing this, you can run a Paper server directly with your plugin in it.Have a look at the Running a server section

To copy our jar to our server, we can simply create our own task.

Have a look at the code. Explanations are shown by hovering over the plus sign for each line.

Note

Although I have no other tasks in my tasks section at the moment, this does not mean that you should create a new task.I just do not show all available tasks every time to keep it as short as possible.

tasks { /*(1)!*/register<Copy>("copyToServer") { /*(2)!*/val props = Properties()  /*(3)!*/val propFile = file("build.properties")  /*(4)!*/if (!propFile.exists()) propFile.createNewFile()  /*(5)!*/file("build.properties").reader().let { props.load(it) } /*(6)!*/val path = props.getProperty("targetDir") ?: ""  /*(7)!*/if (path.isEmpty()) throw RuntimeException("targetDir is not set in build.properties")  /*(8)!*/from(jar)  /*(9)!*/destinationDir = File(path) }}

We register a new task of type 'Copy' and name it 'copyToServer'.
We create our properties
You may need to add an import import java.util.* at the top of the file.
Create a file called `build.properties
We create this file if it doesn't already exist.
We read the file and add it to the properties
We read the targetDir property
We check if the path is empty and throw an error if it is
We define that we want to copy the output of our jar task
We set the target dir of the copy task

Creating a plugin.yml using a Gradle plugin

Now you may or may not have tried this.If you have already created a plugin.yml, it may have worked and failed otherwise.

If you already have a plugin.yml you can delete it now or wait until the end of this section.

To create our plugin.yml we will use the plugin-yml Gradle plugin by minecrell.

Importing

First we need to import it. See the latest version above.

Note

plugins { id("de.eldoria.plugin-yml.bukkit") version "0.9.0" // (1)!}

Replace the version here with the version in the image above

Configuration

Now that this is done, we need to configure our plugin.We do this, of course, in the section of the plugin called bukkit in our case.

bukkit { name = "MyPlugin" main = "dev.chojo.myplugin.MyPlugin" commands { register("test") { aliases = listOf("command") } }}

This is the minimum setup. (Commands are not really needed)What are we doing here?

We define the plugin with the name "MyPlugin".
We define our plugin class.
Please don't make it Main and choose a correct namespace. See my previous blog post.
We will register a command called test with the alias command.

Have a look at the GitHub page for further references.

The version is taken from your project version by default

Bukkit Libraries - The better alternative to shading

You probably remember our dependencies section looking like this:

dependencies { compileOnly("io.papermc.paper:paper-api:26.1.2.build.63-stable") implementation("de.chojo.sadu", "sadu", "2.3.9")}

dependencies { compileOnly("io.papermc.paper:paper-api:26.1.2.build.63-stable") bukkitLibrary("de.chojo.sadu", "sadu", "2.3.9")}

Paper plugins

Paper plugins are a type of plugin exclusively for Paper servers.They are very experimental.They also lack a build in solution for commands and configuration files.If you are a beginner, I strongly advise against using them.

In Paper plugins you can also load dependencies from custom repositories. You can read more about this here.

More about Paper plugins can be found here and here.

Shading dependencies into our jar

Let's assume that SADU is not located in Maven Central, and we cannot use the library loader.

In this case we need to use another plugin called shadow. The latest version is shown above.

Importing

plugins { id("com.gradleup.shadow") version "9.4.1"}

Replace the version here with the version in the image above

Our dependencies look like this again:

dependencies { compileOnly("io.papermc.paper:paper-api:26.1.2.build.63-stable") bukkitLibrary("de.chojo.sadu", "sadu", "2.3.9")}

The purpose of shadow is to copy everything marked as implementation to the output file.

This is already the case if we were to run the shadowJar task instead of the build task.However, building our plugin without shadowJar would result in a jar that is simply broken.

Configuration

We can fix this by telling Gradle that when we run build we actually want to run shadowJar.We do this by configuring the build task to depend on shadowJar.

tasks { build { dependsOn(shadowJar) }}

Relocation

tasks { shadowJar { val mapping = mapOf("de.chojo.sadu" to "sadu") val base = "dev.chojo.myplugin.libs." for ((pattern, name) in mapping) relocate(pattern, "${base}${name}") }}

What this basically does is:

We define a map with the packages we want to move and the directory we want them to move to.
We define the root of the new location of all our shaded libraries.
For each entry in our map, we call the relocate function of our task.

So what does relocation do?
Consider the class de.chojo.sadu.Sadu. After the relocation it will be located at dev.chojo.myplugin.libs.sadu.Sadu.Now that it is in your namespace and your plugin, it is no longer possible for it to collide with another plugin.Shadow will also replace any path to the class in your code with the new relocated path.

Using the output in copy

Warning

Instead of doing this you can directly run a Paper server with your plugin in it.Take a look at the server run section

To use the output of shadowJar for our copy task, all you need to do is change the jar task to the shadowJar task.

tasks { register<Copy>("copyToServer") { val props = Properties()  val propFile = file("build.properties")  if (!propFile.exists()) propFile.createNewFile()  file("build.properties").reader().let { props.load(it) } val path = props.getProperty("targetDir") ?: ""  if (path.isEmpty()) throw RuntimeException("targetDir is not set in build.properties")  /*(1)!*/from(shadowJar)  destinationDir = File(path) }}

Change it here

NMS and internals using the Paperweight Userdev plugin

Adding the repository

For this we need to do something new and go into our settings.gradle.kts to add a plugin repository.

pluginManagement { repositories { gradlePluginPortal() maven("https://papermc.io/repo/repository/maven-public/") }}

Importing

Now we can import the plugin into our build.gradle.kts file.

plugins { id("io.papermc.paperweight.userdev") version "1.7.7"}

This leaves just one step to set up the Paper version.

Configuration

To define the version we want to use, we need to add it to our dependencies.To do this we need to remove the old Paper compileOnly dependency and replace it with the paperweight dependency.

dependencies { paperweight.paperDevBundle("26.1.2.build.63-stable")}

tasks { assemble { dependsOn(reobfJar) }}

Note

In the future Paper plans to use a non-obfuscated jar for servers.This will make this step unnecessary.

And that's it.Now you can use nms as comfortably as possible.

Running a server with your jar

To quickly test your plugin, you can start a server directly.All you need to do is add the run-task plugin to your build file.

I'll refrain from simply copying their readme here, as I can't add any more value to it.

Thank you!

Thank you for sticking with me so far.You now have a very good understanding of Minecraft development with Gradle.

Thanks for reading!If you liked this post, or have some questions, feel free to come by my discord and have a chat!

Or write me a mail at mail [at] chojo [dot] dev.

If you want to support me, feel free to sponsor me via GitHub.

The plugin main class. A constant naming discussion!

chojo — Thu, 03 Aug 2023 13:58:00 +0200

The plugin main class. A constant naming discussion!

German Version

The minecraft main class, or the class which usually extends JavaPlugin, is nearly always subject of discussions when it comes to naming. In this post I try to explain my point of view, and also show my approach on naming them.

To understand why we always discuss this, we first have to understand what the so called Main class actually is.

The java main class

In java, the main class is the class which holds the main method public static void main(String... args).The class holding the main method itself does already not need to be named Main.This main method serves as the entry point into our application.Usually people create their application instance here and build up the startup logic of their application.Without this method our application would never do anything and can not be executed.When we build our application, we also need to point to our main class in our build file, to tell the jvm where to actually find our main class.

The plugin "main" class

The class we call main in our plugins has some very clear differences.

We don't have the main method.
We do not create our own instance of our plugin/application.
We don't have a single entrypoint into our application. In fact, we have at least three:
- Constructor - When the server creates our instance
- onLoad - When the server loads our plugin
- onEnable - When the server enables our plugin
The jvm does not call our main methods itself, but the server does.

"But I declare my main class in the plugin.yml" you might say.Yes we do, however this naming is probably the main issue we have till today.

What we actually declare is not a main class as defined by java, but point at a class extending JavaPlugin or Plugin.The correct naming for this parameter should probably be plugin_class or just plugin.It is not a main class by all means, as defined by java.

The "ideal" name

I personally go with tld.domain.pluginname.PluginName or tld.domain.pluginname.PluginNamePlugin

A plugin with the name Maya by me using the domain chojo.dev would then be named: dev.chojo.maya.Maya or dev.chojo.maya.MayaPlugin

This won't be by far the holy grail for naming.However, this solves two big issues:

1. Namespace conflicts

On minecraft servers we always share the server with multiple plugins which are most probably not written all by ourselves.We might run our plugin on a server with 50 or even 100 other plugins.Therefore, it is important that we choose a unique namespace which is tld.domain.Furthermore, we need to avoid conflicts with our own plugins.That's why we add our pluginname as well and end up with tls.domain.pluginname.Of course, we now have a unique namespace for our plugin already, and we could easily call our class main.I personally prefer to call my class like I call my plugin, so PluginName or PluginNamePlugin to make clearer that the class extends the Plugin class.

2. Class name conflict

"Why not call it Main?" For that to understand, you have to think about the users of your plugin.Or just think about it in general, if everyone would call their plugin class Main.When using an api of a plugin you use the plugin class in at least 90% of the cases.Imagine searching it, and you get a list of 6 Main classes by 6 different plugins.A good start for errors and confusion already.

Or if you use multiple apis or plugin classes in your own plugin by others you would probably end up with something like this:

dev.someone.nele.Main nele = dev.someone.nele.Main.getInstance();dev.someone.lara.Main lara = dev.someone.lara.Main.getInstance();dev.someone.maya.Main maya = dev.someone.maya.Main.getInstance();

Instead, if you follow the naming mentioned above, it would look like this:

NelePlugin nele = NelePlugin.getInstance();LaraPlugin lara = LaraPlugin.getInstance();MayaPlugin maya = MayaPlugin.getInstance();

Isn't this much more readable?We avoid not only namespace conflicts but also class name conflicts. We communicate clearly that our class is a plugin and also directly show our plugins name with it as well.

I don't have a domain

That is not a problem. You probably have a GitHub or GitLab account already and if not I strongly recommend to make one.We use domains because we know that only we use it (ideally).So everything you need is something unique that is bound to you, which is the case when you have a GitHub or GitLab account.In that case you can use io.github.username or io.gitlab.username as your namespace.You can even use this namespace for publishing to maven central!

Conclusion

Plugins should use their own namespace usually using an inversed domain tld.domain, followed by the plugin name pluginname. The plugin class itself should contain the name of the Plugin, optionally suffixed with Plugin to show that it is a plugin class.

So next time you create and name your plugin class (not main class), consider this and choose a better name to make a better world!

Thanks for reading!If you liked this post, or have some questions, feel free to come by my discord and have a chat!

Or write me a mail at mail [at] chojo [dot] dev.

If you want to support me, feel free to sponsor me via GitHub.