Bukkit

Introduction

As you may have noticed, NoLagg consists of components that could be seen as separate plugins. I made that this way to make bug tracking easier and to keep the project healthy. Before it was a really big mess of classes in one package, right now every component is nicely tucked in a separate package folder inside NoLagg. So you may ask...why not multiple plugins in separate jar files?

In short:

1. The Bukkit class loader does not allow it
2. It will increase loading time
3. It will increase plugin size
4. It will complicate source location and plugin dev-bukkit pages
5. It will scatter the plugin too much
6. It is going to result in a core plugin...which is not needed for small plugins

Reason 1: Bukkit class loader

All NoLagg components use the BKCommonLib library to work with permissions, configurations, utilities and other tools. Unfortunately, Bukkit uses a separate class loader for every plugin that is loaded. As a result, every plugin is going to individually load all the classes and methods inside BKCommonLib separately. This has the inconvenient result that, at some point, errors are thrown. See my page about it, there is no solution.

Reason 2: Source code

I would have to make around 14 separate GitHub project source pages for all plugins, instead of having all of them in one project. This is not only impossible to maintain, it is going to raise countless questions of people not knowing where certain source code is. I would have to make a main source page somewhere linking to all these projects, it will become a mess at some point.

Reason 3: Versioning

Every plugin would have to get their own version. NoLagg has one version, so what do I do? I will need to make around 14 separate dev-bukkit pages for all these components. 14 locations for me to answer people's questions. This will result in questions not answered on some pages, or simply put: Outdated pages.

Reason 4: Commands

All components use the /lag main command. It is not possible to register more than one command handler for one command. So how do I solve it, so it can still make all separate plugins use the /lag command? It is going to require a core, a core exactly as I have now. Difference being more jar files to load.

Reason 5: Loading times

If I put all components in a separate plugin, it is going to have to load the configuration 14 times. It is going to have to decompress the jar files 14 times. It is going to have to read the plugin.yml 14 times, have to send a plugin enable event 14 times and have to perform core logic 14 times. Not at all useful for performance, it is going to have detrimental effects.

Reason 6: It is not needed

This is the most important reason. Having separate jar files is entirely the opposite of useful. Some want to argue that it would reduce resources on the server - it is the opposite. More plugin.yml files, more logic for every plugin to launch it up, more file access because of separate config.yml files. Right now, you can disable the components you do not use. This not only prevents it from enabling, no, it goes further than that. The entire class of that component isn't even loaded by the class loader. The entire component will not be loaded into memory if it is not enabled. Separating the components into jar files is not going to reduce the resources loaded on the server, it is going to increase it.

What would be the only reason to separate it?

To reduce the size of the jar file. The NoLagg plugin, in total, is almost 250 kb. Is this reason to split this up into 14 plugins of around 20 kb? No, as this would increase the size of the plugin if you do use all components. And the other reasons described above. Look, if the plugin was 10 mb in size, it was useful, but this is not the case.