Replies: 5 comments
-
I don’t have a huge knowledge of the dependency system, but I would imagine this has the potential to cause huge issues with regards to cyclical and load-order problems. |
Beta Was this translation helpful? Give feedback.
-
Use the In general I'm not too keen on allowing things to be dynamic that are registered in the yml. There's a chance that something like this may be implemented in the future, but, at least for now I'd rather keep this static. The above flag should allow you to access all classloaders for other plugins, so you shouldn't have resolution errors for the time being. |
Beta Was this translation helpful? Give feedback.
-
The thing wasn't certainly just the classloading, but also that the plugin also should be loaded after all other plugins. Is this possible to do dynamically? |
Beta Was this translation helpful? Give feedback.
-
Yeah, it's defo possible, just not sure to what extent here this should be done. I'll reopen this for now. |
Beta Was this translation helpful? Give feedback.
-
I feel like allowing to declare load order dynamically makes it too easy to accidentally introduce cyclic load orders if not careful, it's easy enough as it is with the "right" plugins (B declares load-after A and load-before C, C declares load-before A). |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem?
I maintain a plugin called CraftJS, which currently has a problem with dependencies of the CraftJS-plugins. Currently I haven't released the plugin for broaded use, so I have just added dependencies I need to the CraftJS paper-plugin.yml
Describe the solution you'd like.
Allow bootstrapper code to dynamically add dependencies, soft-dependencies and plugin load-order information.
Describe alternatives you've considered.
Overwriting the getPluginMeta function could maybe work, but I think this could be an good use case for bootstrappers.It was a final method.
Other
No response
Beta Was this translation helpful? Give feedback.
All reactions