Paper fails to load plugins with dependencies through API

[MetallicGoat]

Expected behavior

When a plugin tries to load another plugin (from some location outside of the plugins folder) the plugin's dependencies should be checked against the plugins that are currently loaded on the server, and be permitted to enable if present.

Observed/Actual behavior

When a plugin tries to load another plugin (from some location outside of the plugins folder) paper says the dependencies of the plugin being loaded are missing (even if they are not) and fails to enable the plugin.

Steps/models to reproduce

1. Create a plugin that can load another plugin from an addons folder
2. Create another plugin that depends on the first plugin
3. Place the second plugin in the first plugins addon folder
4. Load the second plugin from the addons folder (through a command or something) using Bukkit.getPluginManager().loadPlugin(file)
5. You will receive an error like this https://pastebin.com/DLYc6Q6n

Plugin and Datapack List

• MBedwars (Our plugin)
• ExtraSpectialItems (The plugin being loaded from an addons folder of MBedwars)
• PlaceholderAPI

Paper version

[23:40:59 INFO]: This server is running Paper version git-Paper-448 (MC: 1.19.3) (Implementing API version 1.19.3-R0.1-SNAPSHOT) (Git: 155aa36) You are running the latest version
Previous version: git-Paper-399 (MC: 1.19.3)

Other

We have been using this API for close to a year now, and was working great until a fairly recent Paper update. I believe the API was broken in Paper's move to their own plugin system, as it works fine on the latest spigot version. Let me know if you would like me to test anything, or need more detailed info. Thanks everyone!

[MetallicGoat]

Hey guys, was wondering if there is anything I can do to make help get this solved. I would create a PR, but I have never worked with paper before, and really have no idea whats going on. I imagine its something to do with the new Paper plugins, but that's all I got. If there is anything I can do, please let me know, I would like to help if I can.

[redbau]

👍 +1 for a fix to this...

I'd like to offer a note about this issue as it's drastically impacted my server / development workflow.

Relying on just /reload to test new plugin code, or worse, having to reboot the server just to test a single change is extremely tedious and slow. Prior to this change the very excellent PlugmanX plugin (https://www.spigotmc.org/threads/plugmanx.484998/page-4#post-4549091) has been a lifesaver and lowered my development cycle times by 10x or more easily.

Please, please, please consider addressing this issue in some way that allows other plugin managers to reload single plugins.

Or does the Paper team suggest another workflow for testing new code that is even easier? I'm all ears, but right now this change is the worst new feature in Paper and I will continue to lobby for an alternative until something better arises.

[electronicboy]

plugin managers have never been supported, it would be 100% on them to try to coax themselves back into working;

loading plugins dynamically is a weird one, we can't really expose this too well given the entire new lifecycle system;

also, hotswapping is generally the preferred method for development where viable; otherwise, design the server so that it's fast to restart, or reload "properly"; data driving the server is ofc going to have a whole host of caveats on this entire setup, especially as we try to catch up with mojang here.

[Owen1212055]

Thanks for bumping this, I’ll try to look into this a bit more here. As the issue in question doesn’t deal with plugman at all.

[MrEAlderson]

plugin managers have never been supported, it would be 100% on them to try to coax themselves back into working;

loading plugins dynamically is a weird one, we can't really expose this too well given the entire new lifecycle system;

also, hotswapping is generally the preferred method for development where viable; otherwise, design the server so that it's fast to restart, or reload "properly"; data driving the server is ofc going to have a whole host of caveats on this entire setup, especially as we try to catch up with mojang here.

Plugin loading and unloading is a part of the Spigot API. Telling them to fix something that is a part of the official docs is a big oof.

The error basically always appears when you call PluginManager#loadPlugin(File)

[electronicboy]

Unloading is not

…

On Tue, 28 Mar 2023, 13:14 Marcel, ***@***.***> wrote: plugin managers have never been supported, it would be 100% on them to try to coax themselves back into working; loading plugins dynamically is a weird one, we can't really expose this too well given the entire new lifecycle system; also, hotswapping is generally the preferred method for development where viable; otherwise, design the server so that it's fast to restart, or reload "properly"; data driving the server is ofc going to have a whole host of caveats on this entire setup, especially as we try to catch up with mojang here. Plugin loading and unloading is a part of the official Spigot API. — Reply to this email directly, view it on GitHub <#8971 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJMAZCD5GQEV4QCQYWAAGDW6LI2FANCNFSM6AAAAAAV3IJLZE> . You are receiving this because you commented.Message ID: ***@***.***>

[MrEAlderson]

Unloading is not
…
On Tue, 28 Mar 2023, 13:14 Marcel, @.> wrote: plugin managers have never been supported, it would be 100% on them to try to coax themselves back into working; loading plugins dynamically is a weird one, we can't really expose this too well given the entire new lifecycle system; also, hotswapping is generally the preferred method for development where viable; otherwise, design the server so that it's fast to restart, or reload "properly"; data driving the server is ofc going to have a whole host of caveats on this entire setup, especially as we try to catch up with mojang here. Plugin loading and unloading is a part of the official Spigot API. — Reply to this email directly, view it on GitHub <#8971 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJMAZCD5GQEV4QCQYWAAGDW6LI2FANCNFSM6AAAAAAV3IJLZE . You are receiving this because you commented.Message ID: @.>

https://hub.spigotmc.org/javadocs/spigot/org/bukkit/plugin/PluginManager.html#disablePlugin(org.bukkit.plugin.Plugin)
It is unloaded after the gc has kicked in. So yes, it is basically supported

[electronicboy]

disabled != unloaded. The plugin is marked as disabled and handlers, etc, unregistered; the plugin is still registered within the plugin manager and instanzialised, nothing is unloaded outside of what the plugin itself does; resources such as the classloader are not closed, etc

bukkit does not, and has never, supported unloading plugins outside of a reload;