Topic/modularize

[skaldarnar]

No description provided.

[keturn]

Trying this out. Observations so far:

1. We're going to have to figure out how to attach a debugger to the built application. The rebuild time is long enough to make debugging-by-println no fun.
2. This is a problem:

   TerasologyLauncher/src/main/java/org/terasology/launcher/util/LauncherDirectoryUtils.java

   Lines 152 to 153 in 88d7bfe

   	public static Path getInstallationDirectory() {
   	final URL location = LauncherDirectoryUtils.class.getProtectionDomain().getCodeSource().getLocation();

   
   it comes back with something under jrt:/, which is some virtual filesystem it has dreamed up for the runtime components, I guess. It's read-only.
   and even if it did come back with the location of the executable on the real filesystem, the deb installer puts it a place that's not writable by users (and presumably the same is true for rpm).
   I am also worried that this is another branch of orphaned code? are these directories actually used? because they're different than the values BaseLauncherSettings reported loading.

also, not related to packaging, but I'm worried the way BundleUtils and LauncherManagedDirectory obfuscates the resource identifier enough that nothing ever noticed that resource doesn't exist.

[keturn]

Just for the sake of experimentation, to see how far it would get, I commented out chunks of LauncherInitTask until it wasn't trying to do impossible filesystem things anymore.

And ... it works? it's a bit dodge, as I haven't been too careful about which parts of the init I cut out, and I suspect it's currently trying to show me an error dialog that's zero pixels wide, but it does display the main stage and attempt to run the game.

I think that's your proof-of-concept.

Also, after all that worry we had about finding a jdk distribution with javafx, Idea is telling me in modules-info that there are two things providing the javafx modules. I think we must get one from liberica and one from the gradle javafx plugin.

[keturn]

I have been poking around with this modularization stuff in an effort to see if it's a blocker for merging #562, and I have not been having a good day of it.

From the CodeFX blog, by the author of the book The Java Module System:

As an example, as of August 2019, the newest versions of IntelliJ, Eclipse, and Surefire all run tests of a module differently: […]
— The JPMS Maturity Model

which led me to a discussion on IDEA's tracker about testing, which seems to be far from resolved.

and this article on Testing in the Modular World.

…

It's left me feeling resigned and pessimistic about this.

Earlier, I thought this was going to take some work, and I had my doubts about the return on investment, but I honestly didn't think it was going to be this hard. I thought we were going to have to learn some things and some new tools but the path would be well-charted.

And now, well… I'm reminded of Python 3 a few years back. When there was one big group of people saying "Python 3 has been out for five years, get on board with the new program already!", and another group of people who had a lot of code to keep running and they and had no desire to dive in to compatibility-breaking changes with a rocky transition plan.

[keturn]

So. Maybe I am having a bad day, and this will all look clearer on another day to someone with brighter eyes.

But right now I am trying to figure out next steps for the other branches.

• I could assume that the spf4j-slf4j-test situation is uniquely bad, given how the whole spf4j-binding thing is the poster child for "classpath conflicts are horrible." If that's the case, we mothball that branch, and I cut any log-testing bits out of Game Runner thread / subprocess improvements #571.

then either

• Game Runner thread / subprocess improvements #571 works against this branch with minimal headache, or
• it doesn't, because of something about TestFX, or Monocle, or ▁▁▁▁?
• we turn in to Java Professional Modularizing Specialists, make 💰 from companies trying to move off of Java 8 before their support contracts are due for renewal, and use it to fund TSOC stipends because we don't actually have any time for Terasology dev anymore.

any other suggestions?