This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Paper Plugin Future Planning #8859
Comments
My suggestion is a more direct support for bstats, so that plugin devs won't have to shade and relocate it into their plugin. |
What I would like to have is a change in the plugin loading system, so when a plugin cannot be loaded or enabled for any reason the server should not start at all. reason: a plugin that cannot be enabled is always a severe misconfiguration of the server and can easily cause additional damage if the server starts anyway. |
Something else that imo could deserve a rework is the Having the server yell that "Plugin X is made with an older version" or something like that because the dev keeps the api version low for backwards compat is a bit annoying... So maybe make it a list? Or allow some format similar to mods where you f.e. can have |
The notion of defining an API version is pointless a) The entire system as it stands is practically just a boolean check for if it's defined or not, there is no branching there b) Why should we determine what API versions the server determines as compatible? When you look at stuff like vault eco, the entire notion of API compatibility is stupid (especially defined by the server), given that they don't even really touch anything inside of bukkit outside of the services API stuff c) The entire system is highly redundant, while maybe having some "built against" might be nice for future hacks, there is no usage for it outside of hacks, I'm not sure that the new system even really cares about that? |
Well, then either remove it, or perhaps make it kinda the oposite way of how it works? Right now this would obviously be pointless as that check wouldn't work on older Paper releases (Unless people would retroactively patch this into their 1.8 forks :P) obviously, but for the future could it be an interesting thing to have as not everyone has any clue how to obtain the current server version and check it against their supported versions... |
Something else that just came to mind: What about a change to the authors option to allow adding a personal link, description, etc? Like f.e. authors:
- name: MainAuthor
description: Core maintainer of the plugin
website: https://example.com
- name: SomeTranslator
description: Provides translations That info could then be included in I think that could be useful in giving people proper credit for what they do instead of just being names in a list only. |
I hope it would make the migration to |
|
How would this look like in terms of code? 🤔 |
Please add the ability to output all commands, usages and permissions in a human readable and obvious way then. Definining commands via the plugin.yml has the major benefit that users can just open the jar with any zip program and check the plugin.yml for the commands and permissions a plugin has. (And yes, I know a good chunk of people that do that, it's not just me) Of course this breaks down in more complex setups and parts of it can already one by other plugins (e.g. easily getting all permissions with LuckPerms) but having an inbuilt way to get such info (potentially even on a sub command/command argument basis) would be pretty nice. |
The big issue is "how do we do that" The entire reason that we don't wanna expose commands inside of the new system is that they'd be tied to bukkits dated command system which has far outstayed its welcome; I guess we could aim to have plugins provide some form of meta when they ask to register a command, but, idk how we'd expose that to users |
So, my suggestions are:
|
I'm still in favour of adding some kind of way for a plugin dev to either define supported or unsupported server versions for their plugin. Maybe even extend this to dependency declarations? It would allow an easier way of telling the user that plugin X doesn't work on server version Y or with plugin version Z, as those versions may lack required API methods a dev either has to make complicated workarounds for (i.e. NMS access) or not use at all. For plugins that don't declare these versions should it just assume you accept any versions. And if doable, allow declarations like Yes, yes, right now there is no use because it's legit only one version (Plugin dependencies on the other hand would have a bigger use out of this already), but it's better to build for the future and have it. |
Simply having it part of some command like |
Wow, looks very interesting! the main question that worries me, will the connection of libraries be somehow improved? Problem example: Current Solution: Solution I want: |
@MelonHell Take a look at the PluginLoader system. https://docs.papermc.io/paper/dev/getting-started/paper-plugins This allows you to dynamically add kotlin, where your classloader will only be open to plugins that you explicitly define in your paper plugin yml. |
Paper should log libraries loaded by a Plugin through its PluginLoader, because as of right now is that not the case, which has the potential risk that someone could load dangerous libs without the user noticing. Questions are:
If doable, a message like |
I think that really should be left up to the implementation of ClassPathLibrary. We can add it to the JarLibrary and MavenLibraryResolver impls, but otherwise the only information we have for logging is a "path". Which is less than optimal for something loaded from maven which should include the coordinates in the log msg. |
I just personally want it to be logged in one way or another. Because without that, server owners wouldn't know what libraries are loaded by a plugin, which would be a security risk as a plugin could be hijacked, have malicious code in form of a lib added and then published as a legit release. While I hate Spigot's rather spammy load messages are they at least transparent here and don't hide the loaded libs. |
Something I find a little tedious right now is that you have to define load-before/load-after separately to the dependency declarations, which can be annoying. If dependencies are just I personally would prefer having a As an example: dependencies:
- name: RequiredPlugin
required: true
- name: OptionalPlugin
- name: RequiredPluginLoadBefore
required: true
load-order: before
- name: RequiredPluginLoadAfter
required: true
load-order: after
- name: RequiredPluginLoadBeforeBootstrap
required: true
load-order: before-bootstrap
- name: RequiredPluginLoadAfterBootstrap
required: true
load-order: after-bootstrap Obviously, this is a minor thing, but I still think having to define the same plugins in your load-after/-before again is a bit tedious to do and only makes the YAML file larger than it needs to be. |
Can't recall where I mentioned that before (I think in the paper plugin PR and on Discord?) but a replacement of the Essentially, when a server admin runs "
|
Will there still be a PluginLoader api along the lines of PluginManager#registerInterface? I maintain a custom implementation of org.bukkit.plugin.PluginLoader and the PaperPlugin update caused me to have to completely reengineer how plugins supported by my api are loaded on Paper (See Jannyboy11/ScalaPluginLoader#20). I would love to work with a stable api, instead of having to rely on server internals which I'm currently doing in order to support Paper. |
I don't think it's a feature that should be introduced by a server platform. You might want to know "hot swap" which is a native feature of some JVM implementation (see JBR) where you can swap methods ,classes, etc. at runtime. IDEA also natively support hot swap feature |
reloading is not exactly a mechanism supported by mojang, as such, it's not something that can be nicely exposed outside of the limited contexts that vanilla allows. Reloading random plugins is not supported by the plugin manager, because you can't just safely unload random plugins at runtime, you'd need to effectively tear down the entire dependendents tree, which just creates cause for more unpredictable behavior. This is not something that java itself supports nicely in the context of these environments, nor is it something we really desire to waste our time on. Not to mention: The entire point of reloading is that it reloads all data, that means that you need to clear the servers state and properly call into the bootstrapers of plugins to actually load data, something which doing on running plugins is probably going to create more issues than it solves. |
I think that this should be implemented in the server software, and not by an external plugin. If it is done in paper it will work much more stable and use less reflection and crutches |
I mentioned a possible solution for reload, which is having an event plugins can listen to, to then decide what to do with that. |
maybe I'm developing plugins wrong somehow, but I always use /plugman reload instead of hotswap during development, since hotswap is very limited now I have to restart the server literally every 5-10 minutes, which takes 5 minutes and discourages motivation |
you can use the jetbrains runtime + hotswap agent to drastically improve the hotswapping capabilities |
this solution will not help, since it will not differ in any way from the custom /myplugin reload. we need to reload the entire jar file |
That's a you-problem honestly. Developing stuff can be time consuming and may not be easy, so why do you want a fundamentally broken system here? |
this system does not prevent me from restarting the server in the same way, but when I know that my plugin does not break in any way from this "broken system" I can speed up development several times |
But you don't know that, the whole point is that it breaks in entirely unexpected ways and causes weird issues, especially with newer plugin API (I.e. would it re-call |
Additionally, this is - again - a you-problem. And don't give me the excuse about it being a config option or even env var for devs only. |
what's the problem with disabling this feature by default and putting it in the config with a huge warning? |
Additionally it's probably straight up impossible to make this work with the upcoming registry modification API. And with more and more things being backed up by a registry this means that a pretty significant part of future plugins won't be able to be reloaded anyways, making a reload feature even less useful. |
now that paper got its one plugin respository it will be great if they can make MPM -minecraft plugin manager it ill be great specially mpm update will save pain |
There already is such software, no reason for us to create such a thing (nor is it relevant to this PR) |
What kind of thing? Never heard of that (And I get the feeling it would be a useless thing anyways) |
Reloading plugins has never been a part of the API, nor is it even possibly
to actually implement fully. If plugins want to half shim this mess into
working, they can, but we're not going to add something that is
unsuportable to the api. Afaik, a plugin or two has already updated for
this, but, there's literally nothing we can do here.
…On Wed, 5 Jul 2023, 11:17 ViaBackwards, ***@***.***> wrote:
Reloading plugins is still a sorely missed feature during development,
plugman reload used to take 2 seconds, whereas a full restart takes 20-30,
I can't use intellij debugging because my test server is remote :/. I know
you say its not "safe" on paper to reload plugins and I get that, but from
real world testing in development the server has never had any issues
except using stale classes, which just causes some data not to refresh, but
when you are a developer you understand that, if you reload a plugin which
another plugin depends on, to refresh the data you need to also reload the
dependants, /plugman reloading 2 or 3 plugins is still 100x faster than
restarting the server.
—
Reply to this email directly, view it on GitHub
<#8859 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJMAZDE4ZI6SR7TLBKGWELXOU5LXANCNFSM6AAAAAAVAM2TKI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I just wont use paper plugins, lol. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
This is created to help forward possible more conversation and ideas that may be prompted under the whole new "paper plugin" umbrella.
With the paper plugin PR released, this allows us to ensure that we are able to remain compatible with previous spigot plugins.
These types of plugins are currently experimental, all API regarding it is subject to change.
Currently, paper plugins won't be offered with much new API, as those are still in the works.
This allows us to prompt for conversation for possible future new features:
General TODO
The text was updated successfully, but these errors were encountered: