Instill devops culture

Why?

Reproducible operating environments all the way from development to production are proven to universally increase time to market, maintainability, cut development costs.

Rolling release strategy can be crucial for agile software, which XMage is, since it’s being developed by adding cards, normally, with tiny patches.

What?

Finalise the @allentiak’s work on making the codebase compatible with modern JDK/JRE

Immediate action points

• Remove changelog viewing functionality, which seems to be the only thing in the codebase that depends on JavaFX
• Remove tests covering changelog viewing functionality, if any
• Remove JavaFX dependency
• Playtest JDK11 builds
• Merge @allentiak’s PR

Further work

• Rewrite changelog viewer without JFX

Decrease the responsibilities of launcher

Launcher is a piece of software that is clearly loved in XMage community, but it is also a source of woe, since it’s capable of destructive updates. Also, launcher is a bit of a pipe dream anyway. If it was a one-click installer for XMage, we wouldn’t have had a “how to install XMage” video recorded in every community out there.

Immediate action points

I propose that we keep launcher doing just what it’s great at as it is, which is:

1. Being a thin piece of software which can be compiled against latest JRE / JDK
2. Installing a compatible, portable OpenJDK / JRE version into the directory it’s ran from (we can have license problems with automatic provisioning of OracleJRE/JDK)

• Remove other functionality, including the capacity for [destructive] updates.

Further work

I propose that moving forward, we turn launcher into something resembling asdf:

• Host rolling release jars as well as “stable” releases somewhere (I can donate traffic and VPS for this)
• Track jars released using “rolling release” strategy as well as releases that are manually marked as “stable”
• Allow to swap active jars, effectively changing versions hither and thither

Make a nix flake so that anyone on any Linux or mac os can build jars with 0 overhead

The key feature of nix is that it allows multiplexing the same piece of software, library, etc. For example, with nix you can have a particular version of JRE / JDK isolated just to your project.

Immediate action points

• Allow for nix develop with a flake.nix

Further work

• Allow to build and publish jars with just nix build, without the developers needing to run mvn package

How will it impact the community?

1. Even if the procedure will not be completely automated, it will still be possible for any contributor to make a release, and crucially for any community to use arbitrary commit, even unpublished, even if all the contributors are absent
2. It will be trivial to upgrade a server, since all that changes are packaged jars. No more accidental config rewrites
3. Flexible trust: one can choose to trust some server’s maintainer to pick correct jars and just install whatever they advertise
4. No need to reinvent the wheel when it comes to redistributing Java for the end user, this part stays the same and it’ll be virtually the only real role of launcher at first

[weirddan455]

Regarding the launcher, I wrote an alternative a while back using C++/Qt. Basically, my goal was to get a step closer to a “one-click” solution removing the need for the user to have Java installed to run the thing that sets up Java for XMage. On Windows, a statically linked binary is available so no external dependencies need to be installed for the user (should be possible to do the same on Mac but I don’t have one to test on).

I’m not sure if this is the direction the project wants to go or not but I’ll link if anyone is interested.

https://github.com/weirddan455/xmage-launcher-qt

[cognivore]

Finalise the @allentiak’s work on making the codebase compatible with modern JDK/JRE

Implemented independently by me https://github.com/cognivore/mage/tree/issues/8749 and by a contributor https://github.com/fburato/mage/pull/38/files

See #8749

Nix is also added and is demonstrated to work in my patchset.