Add an AnnoyingLoader class which is what extends JavaPlugin. Then this will load the consumer plugin that extends AnnoyingPlugin.
Consumer plugins will need to set main class in plugin.yml to {package}.libs.{annoying_package}.AnnoyingLoader and AnnoyingLoader will somehow have to know which class extends AnnoyingPlugin (or maybe it can just use reflections library?).
This will allow for better type accessing in consumer main classes (like OkaeriConfig classes). As then runtime libraries can be loaded before being used/loaded at all.
There should also be some sort of LoaderOptions or something so that custom required libraries can be specified (and any other details/options).
Since AnnoyingPlugin will no longer extend JavaPlugin, it needs to hold a reference to AnnoyingLoader (new JavaPlugin extender) as a variable instead. So instead of something like plugin.getName(), we'd need to do plugin.loader.getName(). But we aren't often using JavaPlugin's methods, so this isn't too significant.
Another potential issue is dependents/other plugins that use getPlugin(PluginClass.class) or PluginClass plugin = getPlugin("name"). These will no longer work as expected because the plugin class is now AnnoyingLoader (relocated, so conflicts aren't an issue), not PluginClass. But I doubt anything is actually using these methods for any of my plugins anyway. But, just to ensure this can still be possible, AnnoyingLoader should contain a reference to its loaded plugin.
This also has the added bonus of separating onEnable, onDisable, etc. into an outer, unmodifiable class. So it is more difficult in overriding those.
New idea
Make a completely separate repository/project for AnnoyingLoader that contains ONLY the loader, Libby, and runtime libraries list.
That way, Annoying API itself can ALSO be a runtime library, with Annoying Loader and Libby being the ONLY things packaged/embedded in the plugin.
Alternative
Or, have both a separate project for Annoying Loader AND an internal separate loader in Annoying API or something.
That way, Annoying Loader + Libby are still the only things packaged/embedded in the plugin, but Annoying API's own runtime libraries can still be defined/loaded in the API, rather than in the loader. This makes the loader much less volatile and "permanent."
Add an AnnoyingLoader class which is what extends JavaPlugin. Then this will load the consumer plugin that extends AnnoyingPlugin.
Consumer plugins will need to set main class in plugin.yml to
{package}.libs.{annoying_package}.AnnoyingLoaderand AnnoyingLoader will somehow have to know which class extends AnnoyingPlugin (or maybe it can just use reflections library?).This will allow for better type accessing in consumer main classes (like OkaeriConfig classes). As then runtime libraries can be loaded before being used/loaded at all.
There should also be some sort of LoaderOptions or something so that custom required libraries can be specified (and any other details/options).
Since AnnoyingPlugin will no longer extend JavaPlugin, it needs to hold a reference to AnnoyingLoader (new JavaPlugin extender) as a variable instead. So instead of something like
plugin.getName(), we'd need to doplugin.loader.getName(). But we aren't often using JavaPlugin's methods, so this isn't too significant.Another potential issue is dependents/other plugins that use
getPlugin(PluginClass.class)orPluginClass plugin = getPlugin("name"). These will no longer work as expected because the plugin class is now AnnoyingLoader (relocated, so conflicts aren't an issue), not PluginClass. But I doubt anything is actually using these methods for any of my plugins anyway. But, just to ensure this can still be possible, AnnoyingLoader should contain a reference to its loaded plugin.This also has the added bonus of separating
onEnable,onDisable, etc. into an outer, unmodifiable class. So it is more difficult in overriding those.New idea
Make a completely separate repository/project for
AnnoyingLoaderthat contains ONLY the loader, Libby, and runtime libraries list.That way, Annoying API itself can ALSO be a runtime library, with Annoying Loader and Libby being the ONLY things packaged/embedded in the plugin.
Alternative
Or, have both a separate project for Annoying Loader AND an internal separate loader in Annoying API or something.
That way, Annoying Loader + Libby are still the only things packaged/embedded in the plugin, but Annoying API's own runtime libraries can still be defined/loaded in the API, rather than in the loader. This makes the loader much less volatile and "permanent."