How to deal with CraftBukkits SafeGuard?

[MyPictures]

In NoCheatPlus we use @mbaxters idea of modular based compatibility which brings advantages and disadvantages:

• Will take quite long to compile because you need to download all CraftBukkit versions to do it
• Comes to problems when we try to use new features which are available in the new CraftBukkit builds but are missing in the old ones (limitation). Typical example: FastEat and FastConsume (We need to do a kinda mess then)
• Never know when we should drop support for some versions
• Downwards compatibility

Any ideas for a better system to access NMS? As far as I know DBO (dev.bukkit.org) disallows the usage of reflection to get around this one.

[asofold]

With on-the-fly adding and overriding checks and data source providers as well as generic registry supporting some handling of dependencies including factories for such components we might be able to have more flexible approaches to this.

Concerning the project setup with Maven we could thus afford to make a plugin for old server versions that adds the checks and data source providers specific to that version, while the components that can only run with the later versions of the server software will not install in the first place. Still a matter of taste is if to use multiple projects for the different dependency modules, or to use one project with multiple sub-modules - i opt for using multiple projects this time. We should always support some versions of CB with our main plugin version, for which mcstats might stay a useful place to check (versions in use).

All provided we achieve implementing these aspects of the registry.

So here the core framework with the generic registry running independent of other API/server-impl would be a good thing to have.

[MyPictures]

If that's the plan then I vote for then multiple projects also. I kinda think this is the point were we could use the GitHub branches system (NoCheat/1.4.6/1.5.1). With this we could still push critical bug/crash fixes for all builds and still be able to use new features of CraftBukkit in the new NoCheat builds.

[SuperSpyTX]

I'd say all the NMS code should almost be like last time, but this time instead of hardcoding v1_6_2 in the file, have a constants class where the version is imprinted. Reflection would still have to be used, but instead of using it to find the version, it would be used to access NMS.

Obviously however, there should be an abstract API.

As for compatibility, I don't like downloading several 20-15 MB JARs to compile NoCheat. Instead, I'd prefer we download just two, or if we can, avoid downloading them at all. The best way we should be accessing NMS is without having to import the package, and rather use reflection to access it. The reflection part would not be used to find the version as I mentioned, but rather used to access it without referencing the original CB JAR.

This way we can easily compile NoCheat while saving bandwidth you guys preciously have to save consistently.