search

CivMC / Civ

Monorepo for development of and running a Civ Server.
MIT License
4 stars 11 forks source link

Refactors dependency gluing #392

Closed Protonull closed 1 month ago

Protonull commented 6 months ago

This PR refactors the APIs provided by CivModCore that were intended to help hooking into soft dependencies. Now, any plugin that wishes to create a dependency glue need only do the following:

  1. Ensure that CivModCore is declared within the depend or softdepend lists in your plugin's plugin.yml

  2. Create a class that will NEVER be touched by any other code, eg: src/main/java/net/civmc/example/glues/NameLayerGlue.java Which must implement the DependencyGlue interface.

  3. Create a resource called glues.properties and with the content:

    NameLayer:net.civmc.example.glues.NameLayerGlue

    Where the key is the name of the dependency and the value the class-name of the glue.

  4. Done.

That's it... the glue class will be initialised when CivModCore detects the dependency is enabled for the first time and then invoke enable(). If the dependency is disabled at some point, the disable() method is called. Any subsequent re-enabling will call enable(), etc.

This does mean that glues cannot themselves be API interfaces: the entire point is that they're only interacted with by CivModCore's GlueManager class, but this is a great way of safely registering listeners and such without fear these kinds of issues, since the class is never initialised if the dependency is not present.

Protonull commented 3 months ago

Hmmm, starting to wonder whether this refactor is moot: the server is just the compiled output of this monorepo; there'll NEVER be a question over whether NameLayer, or Citadel, or JukeAlert, is missing, unless we delete those plugins from the monorepo... which is unlikely. In addition, Okx has said that we should stop pretending that we aren't the only ones who consume our APIs (reference), and SoundTech has said that all changes must be tested with a local docker instance (reference) because it replicates the server as closely as possible. With these things in mind, I'm wondering whether it'd be better to yeet this boilerplate altogether and convert all our soft-dependencies into hard-dependencies.

Protonull commented 1 month ago

Closing due to a lack of interest.