Plugin APIs and implementations

[Protonull]

When the civ-suite was updated to Minecraft 1.18.x, it necessarily required a switch over to Gradle. Each plugin that was updated had all its code moved to a paper subfolder. This was ostensibly done to allow support for multiple NMS versions and potentially even other platforms:

However, there has been zero progress towards this. Indeed, we've just surpassed NameLayer's second anniversary of being Gradle'd, and yet it's further from that vision now than before. NameLayer had code to make it work over multiple versions, and even on Bungee, an entirely different platform; NameLayer should've been the shining example of this vision, and yet it remains conspicuous in its nonfeasance.

There is a real opportunity now to push towards this vision, or abandon it. NameLayer needs a good clean up, and NameColors' going to be merged into CivChat2, and CivChat2 itself needs a good clean up to move away from legacy colours and formatting.

[Protonull]

Personally, I am of the opinion that the api/implementation split should be abandoned, here are my 13 reasons why:

1. The likelihood of ongoing support for older versions is minimal at best. Even prior to NameLayer's Gradle-ification, new features were not tested with ANY of its other supposedly supported NMS versions. Indeed, NameLayer now includes some use of Kyori components, which makes NameLayer more or less incompatible with Minecraft below Paper 1.16.5 (473). It's a safe bet that this was never tested for, or even considered. This will likely continue. It's also civ-tradition to not offer support to older versions, take CivModCore's README for example, which says: "No explicit backwards support is offered to any previous version, whether it be major, minor, or patch."

2. The likelihood of other platform implementations (Forge, Fabric, Minestom, Sponge, etc) is effectively zero. I would hazard a guess that anyone committed enough to do such a drastic refactor would just make an entirely new and separate project, eg: CivTest (CivCubed did this too without even changing platforms). And the implications for how much this would complicate the plugin API are staggering.

3. The likelihood of contributions from fellow civ-iterations is minimal at best. CivMC, Civclassics, DevotedMC, CivEx, CivRev, etc, all had/have their own distinct organisations with their own forks, and it's immediately obvious why: why would you forego a neat collection of your own permanent forks, for a random collection of temporary forks while you wait for some crusty long-quit dev to merge your upstream PR? And devs aren't going to go out of their way to make nice and concise upstream PRs, otherwise why hasn't CivMC done exactly that to Civclassics or DevotedMC?

For these reasons, I don't think it's worth the time, effort, and gatekeeping that'll come with this. It would be best if civ-plugins went back to being provided as-is.