What is ONIX?
ONIX is an essential plugin with a complete modular structure. You can choose which modules you (don’t) want to load.
Finished Modules:
Why did you release it that soon?
I want you to make suggestions for further modules I should implement. The beginning is a warp module.
Features:
I’m not exactly sure what you define “modular” to be, but looking at the code it’s certainly not what I would consider modular.
I couldn’t help but notice, that Warps is, in fact, an integral part of the plugin - playing a big part in the very main class. It’s not easily interchangeable and the commands are registered in the main class.
Also, SpongeAPI has a very nice way to let other plugins access different APIs within your plugin called services. I feel like it’s something that everyone should use in a general-use and modular plugin.
Before you continue, I would suggest rethinking the structure of this plugin, so that you could easily register and disable different parts (modules) of your plugin, if you care that much of modularity. I wish you the best of luck regardless.
I already noticed the problem, that this isn’t really modular. I’m currently working on a system that allows everyone to make his own modules without modifying anything of the code. So I’ll be able to load modules from a folder.
That seems kind of backwards. We already have the ability to create plugins to add functionality. There is really no need to create trivial plugins for plugins, that add trivial functionality. If you’re gonna have something as trivial as Warps be it’s own plugin, that is a bit of an overkill.
I can understand having a family of full-featured plugins that have a shared dependency, kind of what Essentials did, but if every little feature, such as Warps, Homes, Teleporting, spawning items, etc. has it’s own plugin, it’s going to quickly become a mess.
There won’t be plugins. The Jar-Files (modules) will get loaded dynamically to the runtime by ONIX. That will make it possible to add functions to the server without adding plugins. ONIX will behave like it has every module’s code implemented.
That is essentially a plugin.
Then I don’t know how to make this more modular without loosing the actual sense of plugins.
A classic system of internal modules should work. It’s usually done by having some kind of interface that encompasses some kind of functionality. If the module is enabled - register that implementation, skip it otherwise.
The interface:
public interface Module {
public void registerModule();
}
The module:
public class ModuleWarps implements Module {
void registerModule() {
//load warps config, register commands, register services
}
}
Then you can make a list of instances for enables modules and run registerModule() for each of them.
Pushed to Git, thanks for your help 
I’m glad to be of help!
@leNic
So basically, this is a giant plugin with a configuration section to disable the sections or ‘modules’ the admin doesn’t want? For example if I wanted the homes and warps but I didn’t want jail I would just set the Jail to false in the config. Or would it be like, I put the Warps.jar and Homes.jar into a ‘modules’ folder that gets handled by your plugin to load into the server.
ONIX will have a lot of functions. To reduce server load and to keep everything clear, you can disable every function in the config.
How does it reduce server lag and keep things clear? One giant plugin is basically the same thing as having the 5+ of the things in separate plugins. IMO, having folders for each plugin along with their .jar is more organized with a plugin say having 4 folders, each holding the config for their feature.
[edited this post on accident instead of replying to another one, so just ignore the edits 
]
Not needed commands or listeners won’t be registered. It also improves compatibility with other plugins.
Instead of using your own module system, use the systems for inter-plugin communication provided by Sponge:
https://docs.spongepowered.org/en/plugin/advanced/services.html
Every “module” should be a standalone Sponge plugin that communicates with other modules (that is the difficult part). Ideally there is no need for a “core” module.
The modules are not external. They are already implemented but toggleable.
In theory you could make addons, that are basicly sponge plugins that register commands/listeners through the OnixModule interface.
Get what your saying but your sort of reinventing the wheel.