Alternative Techniques

Utilizing non-plugin-libraries in plugins isn't new. Here, we present and discuss old methods to achieve this.

Classpath Method

If you are willing to change your server startup script, you can change the java command to start the server into something like this:

java -cp "lib/*:spigot-1.8.8.jar" org.bukkit.craftbukkit.Main

This includes everything in lib/ into the application classpath along with the server jar. Because we use the classpath option -cp instead of -jar, the main class to run also needs to be specified.

One upside of this method is that it is pretty clean, the libraries are available in the root application classloader instead of some hacky runtime classloader whose implementation differs for different server versions. Before PluginLibrarian, this solution was considered for TomatenCraft.

The major downside here is the need to dictate a non-standard startup script. Of course this is not hard to do, but it would become a real bother to have to tell external users to mess with their startup script/habits to use any of your plugins. This is hardly an option for public plugins.

Bundling Method

Used libraries can be bundled into the plugin JAR file, effectively making them part of the plugin instead of loading them from another file. Buildtools automate this bundling, making it easy to generate such a plugin JAR file.

This appears to be the standard way others use libraries in plugins.

One major upside of this method is the ability to provide plugins as stable, standalone JAR files.

But there are critical downsides to this. Copying libraries into every plugin will disable proper package management. Old library versions will stick around in different plugin builds for long times, without indication, resulting in updates, including patches and security updates, not being applied anytime soon. Secondly, bundling the same library into multiple plugins running simultaneously is prone to issues, especially when having different library versions or shared library access.

Pluginification Method

One can modify a library JAR file to become a plugin by simply adding a generic plugin.yml and empty plugin main class.

In the past, this has been done manually for some external libraries used by TomatenCraft. Some internal libraries were created as plugins because they happened to only be required by plugins.

Though I am not aware of any such tool, it wouldn't be hard to automate this JAR file conversion, possibly yielding a more scalable method. Still, these pluginified libraries are different builds and would need to be placed in the plugins folder by a package manager, probably necessitating a separate package definition.

Why to use PluginLibrarian

PluginLibrarian simply includes given libraries, similar to the Classpath Method but without requiring a modified startup script.

This enables to use TomatenPack for installing and updating plugins and their dependencies, including libraries. The libraries do not need any special individual care.

Users can simply tomatenpack install plugins into their server and they will work properly without additional steps.

PluginLibrarian coexists well with other plugins using other approaches.

The only downside is that PluginLibrarian's implemetation is relatively hacky. It already contains two different implementations for different server versions.

But I think the concept is more important than the implementation here. I am pretty committed to getting this to work properly in any server version that awaits, by any means.