Now I understand bloatware

I have not written in a while, which is not good. But, I have been so busy between RL work and my software work that I just have not had the energy or time. When I am at home, I have been working on learning how to package my adventure game. It is not as easy as it looks. I would liked to have written this post as a mini-howto on packaging via jpackage, codeberg, and github. Yeah, it’s not happening yet.

Background and beginning

If you read my previous post, you know that I recently spent a good deal of time debugging a Java build of a program. Not a bug in the Java code, but a bug in gradle, my build environment. Specifically, in my gradle build file: build.gradle.kts.

After going through that problem, I spent time, finally, not pursuing more programming, but learning how gradle’s build operated instead. So, this is a summary of that learning. Sorry, it’s going to be a bit long. But, first, I need to take a minute to go over background things so that we are all on the same page. If you read my post about writing and compiling a Hello World! program in C and in Java , you will know what a basic Java program looks like. You will also see that, in theory, you can compile a Java class with javac MyMain.java into a program.

A sleeping build time bug arises

I haven’t written in a while. Sorry. It’s hot here and I’ve been spending extra time working on the adventure game . I sat down to start writing some of the unit tests for the game. I wanted to do one simple one and test to see if everything built and tested correctly. I always do things in code incrementally; a little at a time and test. Sometimes, it seems pedantic, but it pays off. Though it was not expected to fail, JUnit pushed a failure during testing that hadn’t been there when no tests were available.