Modernise configuration processing used in `Mage.Server`

Why?

As a part of effort to be compatible with JDK11+, we need to make sure everything, including Mage.Server, builds with mvn package. Currently, due to JAXB deprecation, it is impossible to generate Config class from ConfigFactory. It should be noted, that I have tried to use every drop-in JAXB replacement out there, including jaxb-api + jaxb-impl dependencies and Spring’s implementation, and all of those attempts failed.

What?

• Provide Config class with an API similar to the existing one (see ConfigFactoryTest)

How

Strategy A

Admittedly, the lowest hanging fruit is to start by manually making a module which would follow current config’s XML specification, perhaps even by slightly retouching the generated ./target/generated-sources/xjc/mage/server/util/config/Config.java. A huge drawback of this approach, is that it destroys the single source of truth, which is the XML schema, creating maintenance strain whenever config schema is changed. That said, I don’t see it as an event that happens all too often, this is why I think it’s a possible angle of attack.

~- [ ] Add a manually crafted or machine-generated Config.java to the codebase~ ~- [ ] Update tests to refer to Config class directly, rather than ConfigFactory~ ~- [ ] Comment out code of ConfigFactory, referring to this issue~

Strategy B

The proper way to solve this issue is to not search for a drop-in replacement for JAXB, but rather incorporate a modern approach for dynamic class generation based on XML specifications. I’m yet to learn how it’s done in Java 11+, but I’ve already asked an expert Java developer to have a look and, perhaps, he’ll provide some pointers.

~- [ ] Find out how JAXB-like functionality is implemented in modern Java~ ~- [ ] Rewrite ConfigFactory to use that modern approach~ ~- [ ] Adjust Config API (over which we won’t have control in Strategy B) throughout the codebase, including ConfigFactoryTest~

Strategy C

Perhaps, my lack of experience with mvn/pom.xml is the source of me failing to make a JAXB drop-in replacement work. If so:

• Find a JAXB drop-in replacement
• Add it to the dependencies
• Make sure it works
  • at build step,
  • test step,
  • runtime

[fburato]

@cognivore: I’ve tried it out as well and I managed to get a running version that incorporate everything (JavaFX and JAXB). fburato/mage#38 builds with the simplest possible invocation (mvn clean install), has all tests passing, and runs with the client and the server starting without issue and managing to connect to one another.

[fburato]

@cognivore: it’s probably because VSCode is wiring in the classpath when you launch the client from the IDE. That’s what I meant in my comment to @weirddan455 with “I don’t know exactly how you are running the application”, and more generally when the application is packaged it is important to ensure that the lib folder that is added in the client contains all the necessary dependencies. I’m not familiar enough with the release process of Mage to know how that works, but I assume there is going to be another change to make to include the new dependencies.

More generally, however, I was suggesting to add the JARs in the classpath manually just to confirm that the application would run that way. Figuring out how to automate the addition comes after we have validated that the hypothesis is correct 😃