Add a plugin system

[natanbc]

Currently it allows loading from both jars and folders with classes.

An example implementation can be found in LavalinkServer/src/example-plugin

[freyacodes]

It looks like the classloading is handled after Spring has started. To my understanding, this means that dependency injection isn't applied to these classes. If plugins are subject to dependency injection it would allow much greater flexibility.

The obvious problem is that the classloading requires the plugin configuration to be loaded by Spring. Perhaps this problem can be solved by using an initial spring context to only loads this configuration before the full application is launched.

[freyacodes]

In addition to documentation (an example is not enough), I think this feature needs a boilerplate project that developers can fork. This would probably be a separate repo with an example plugin similar to the one you showed.

Would you be interested in working on such a boilerplate, or should I?

[natanbc]

I tried getting jitpack to build the server so it could be added as a dependency on the boilerplate project, but there's currently no support for jdk 10, so this happens. A temporary workaround would be setting server source/target compatibility to 9, at the cost of not using java 10 features (although none are used currently, and building with target as java 9 works).

[schnapster]

Put this into the jitpack.yml:

before_install:
- wget https://github.com/sormuras/bach/raw/master/install-jdk.sh
- source install-jdk.sh -F 10 -L GPL

[schnapster]

Why are you trying to publish the server via jitpack tho? It's a standalone application, not a library.

[natanbc]

Why are you trying to publish the server via jitpack tho?

To be able to write this

This would probably be a separate repo with an example plugin similar to the one you showed.

without having to copy lavalink classes/source to the project

[schnapster]

Imo that means Lavalink should publish a public API / contract, not the whole server project.

[natanbc]

Linkink to the server allows plugins to access server classes, and eg read server configurations with spring dependency injection.

While a public API could be implemented to provide similar functionality, it would limit access to server code or require adding all methods to it, which is why I chose to have the server as a (compileOnly) dependency.

[schnapster]

No public API / contract and importing the whole thing means downstream will just have to eat any changes to the server project.

[natanbc]

@napstr how's this?

[schnapster]

Creating an interface of all the important internal classes does not make an acceptable public API in my eyes.

[schnapster]

This PR seems, for a reason I don't understand, insisting on making internal Lavalink classes public API.
That is a concern very separate from, even if dependent on by, a plugin system, and I suggest doing that in a separate PR so that existing contributors and especially the parties interested in having a public API of lavalink classes have a chance at defining, which, if any, parts of Lavalink should be a public API.
A well written draft document about how Lavalink works will surely help for that to move forward.

[freyacodes]

@natanbc it would be great if you outlined what sort of functionality you want plugins to access. It's difficult to construct an API if you don't know what the goal is. Judging by your code one such goal is to support custom WS ops.

Let's say we want plugins to define custom WS ops. Instead of directly overriding the methods in the WS server, we could instead allow plugins to register ops on a per-plugin basis, which will be invoked if the ops are not already defined directly in the server. This wouldn't touch on any internal class from the plugin's perspective.