Custom libraries support

[BSFishy]

trafficstars

So I am working on a plugin, and notice that a few libraries are added upon starting the server. Since it is obvious that you cannot contain everything in your own code, I think it would be a nice feature if you had the choice of putting some maven packages in your plugin.yml or some other file. The server would then download those packages, put them into the libs folder, and add the to the classpath or whatever it does with the other libraries.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[gdude2002]

This was actually the original intention for this feature. I'm not sure if the plans changed, though.

[mastercoms]

Yeah that feature is still pending.

[smartboyathome]

I can start working on this, but my question is do we want to extend the plugin.yml or introduce a new YAML file? I would probably go with the latter, unless we want to try to get the other servers to support this.

[mastercoms]

I think we should have both. Server owners should be able to specify dependencies they need in case of plugins that have not updated with plugin.yml.

[smartboyathome]

Okay, so after going through the code, here's my planned tasks:

1. Allow server owners to specify libraries using the glowstone.yml file. With this, it should be possible to remove the static specifications of libraries from LibraryManager.run() and instead include them in the default config.
2. Allow plugins to specify libraries using their plugin.yml file.
3. Verify dependencies against the server's shaded dependencies in order to detect conflicts.

For 1 and 2, my proposed changes to the config are to add a section as follows:

libraries:
    - group-id: org.apache.commons
      artifact-id: commons-lang3
      version: 3.7
      repository: https://repo1.maven.org/maven2/
      checksum:
          type: md5
          value: c7577443639dc6efadc80f1cbc7fced5

Most of these properties should be pretty self explanatory. The only required fields are "group-id", "artifact-id", and "version". "repository" and the "checksum" section are both optional, with "repository" specifying an alternative Maven repository for dependencies not in Maven central, and "checksum" specifying a statically defined checksum to validate against. The checksum types that we support would be the same ones that are being defined in #802.

While some libraries may not exist in a structured Maven repo, this should be enough for the minimum viable product, a nd in the future it should be easy enough to allow someone to specify the "url" property instead of "group-id", "artifact-id", "version", and "repository".

Hoping to get some feedback on this. If you think this is acceptable, then I will start work on it after #802 gets merged.

[smartboyathome]

So, as outlined above, Bukkit is pretty straight forward. Sponge is not, since, from what I understand, it uses annotations to define its plugins rather than config files. One idea I had was to look for a "libraries.yml" file, which could be agnostic no matter what the plugin type is. But, for some plugin types such as Canary plugins, this would be a different type of file. I'm open to suggestions if anyone has a better idea.

[aramperes]

@smartboyathome Supporting plugin types other than Bukkit (like Sponge and Canary) is not a priority (at all). We don't support other types (they are just detected), except for Sponge which can be bridged with Bukkit2Sponge (but from my understanding, we are months behind Sponge updates)

[aramperes]

AFAIK this feature is now implemented, but it needs documentation. Is that correct @smartboyathome?

[mastercoms]

https://www.spigotmc.org/threads/spigot-bungeecord-1-17-1-17-1.510208/#post-4184317