2022-04-18 18:12:39 +02:00
|
|
|
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
|
|
|
|
From: Xemorr <31805746+Xemorr@users.noreply.github.com>
|
|
|
|
Date: Fri, 1 Apr 2022 19:57:40 +0100
|
|
|
|
Subject: [PATCH] Update Folder Uses Plugin Name
|
|
|
|
|
|
|
|
|
|
|
|
diff --git a/src/main/java/org/bukkit/plugin/SimplePluginManager.java b/src/main/java/org/bukkit/plugin/SimplePluginManager.java
|
Ignore invalid jars inside of the updates folder (Fixes #7751)
This really needs a deeper look here, the way updates are handled is
fairly immature, but, this wasn't ever intended to be a large scale thing
Ideally, imho, we'd collect the list of update files into some form of Map,
that way we just have a reference of Name > File refs, and can filter out
cases where there are two versions of a plugin in there and warn expectidely,
but, that creates some complications, you would need to fall back to a dir
scan in the case of a plugin calling loadPlugin, but, it would at least
give us more defined behavior, as well as improve performance here vs
repeatidely trying to deserialise the plugin.yml defs for every file
in there on every load
2022-04-20 11:00:50 +02:00
|
|
|
index 42da20011544075a9bea63a12ae86f2f21720667..bab8bb3a52cdeef5f7052d4e3f404c42f37d117d 100644
|
2022-04-18 18:12:39 +02:00
|
|
|
--- a/src/main/java/org/bukkit/plugin/SimplePluginManager.java
|
|
|
|
+++ b/src/main/java/org/bukkit/plugin/SimplePluginManager.java
|
|
|
|
@@ -400,7 +400,7 @@ public final class SimplePluginManager implements PluginManager {
|
|
|
|
public synchronized Plugin loadPlugin(@NotNull File file) throws InvalidPluginException, UnknownDependencyException {
|
|
|
|
Validate.notNull(file, "File cannot be null");
|
|
|
|
|
|
|
|
- checkUpdate(file);
|
|
|
|
+ file = checkUpdate(file); // Paper - update the reference in case checkUpdate renamed it
|
|
|
|
|
|
|
|
Set<Pattern> filters = fileAssociations.keySet();
|
|
|
|
Plugin result = null;
|
Ignore invalid jars inside of the updates folder (Fixes #7751)
This really needs a deeper look here, the way updates are handled is
fairly immature, but, this wasn't ever intended to be a large scale thing
Ideally, imho, we'd collect the list of update files into some form of Map,
that way we just have a reference of Name > File refs, and can filter out
cases where there are two versions of a plugin in there and warn expectidely,
but, that creates some complications, you would need to fall back to a dir
scan in the case of a plugin calling loadPlugin, but, it would at least
give us more defined behavior, as well as improve performance here vs
repeatidely trying to deserialise the plugin.yml defs for every file
in there on every load
2022-04-20 11:00:50 +02:00
|
|
|
@@ -427,16 +427,56 @@ public final class SimplePluginManager implements PluginManager {
|
2022-04-18 18:12:39 +02:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
- private void checkUpdate(@NotNull File file) {
|
|
|
|
+ // Paper start - Update Folder Uses Plugin Name to replace
|
|
|
|
+ /**
|
|
|
|
+ * Replaces a plugin with a plugin of the same plugin name in the update folder.
|
|
|
|
+ * @param file
|
|
|
|
+ * @throws InvalidPluginException
|
|
|
|
+ */
|
|
|
|
+ private File checkUpdate(@NotNull File file) throws InvalidPluginException {
|
|
|
|
if (updateDirectory == null || !updateDirectory.isDirectory()) {
|
|
|
|
- return;
|
|
|
|
+ return file;
|
Ignore invalid jars inside of the updates folder (Fixes #7751)
This really needs a deeper look here, the way updates are handled is
fairly immature, but, this wasn't ever intended to be a large scale thing
Ideally, imho, we'd collect the list of update files into some form of Map,
that way we just have a reference of Name > File refs, and can filter out
cases where there are two versions of a plugin in there and warn expectidely,
but, that creates some complications, you would need to fall back to a dir
scan in the case of a plugin calling loadPlugin, but, it would at least
give us more defined behavior, as well as improve performance here vs
repeatidely trying to deserialise the plugin.yml defs for every file
in there on every load
2022-04-20 11:00:50 +02:00
|
|
|
+ }
|
2022-04-18 18:12:39 +02:00
|
|
|
+ PluginLoader pluginLoader = getPluginLoader(file);
|
|
|
|
+ try {
|
|
|
|
+ String pluginName = pluginLoader.getPluginDescription(file).getName();
|
|
|
|
+ for (File updateFile : updateDirectory.listFiles()) {
|
|
|
|
+ if (!updateFile.isFile()) continue;
|
|
|
|
+ PluginLoader updatePluginLoader = getPluginLoader(updateFile);
|
|
|
|
+ if (updatePluginLoader == null) continue;
|
Ignore invalid jars inside of the updates folder (Fixes #7751)
This really needs a deeper look here, the way updates are handled is
fairly immature, but, this wasn't ever intended to be a large scale thing
Ideally, imho, we'd collect the list of update files into some form of Map,
that way we just have a reference of Name > File refs, and can filter out
cases where there are two versions of a plugin in there and warn expectidely,
but, that creates some complications, you would need to fall back to a dir
scan in the case of a plugin calling loadPlugin, but, it would at least
give us more defined behavior, as well as improve performance here vs
repeatidely trying to deserialise the plugin.yml defs for every file
in there on every load
2022-04-20 11:00:50 +02:00
|
|
|
+ String updatePluginName;
|
|
|
|
+ try {
|
|
|
|
+ updatePluginName = updatePluginLoader.getPluginDescription(updateFile).getName();
|
|
|
|
+ // We failed to load this data for some reason, so, we'll skip over this
|
|
|
|
+ } catch (InvalidDescriptionException ex) {
|
|
|
|
+ continue;
|
|
|
|
+ }
|
2022-04-18 18:12:39 +02:00
|
|
|
+ if (!pluginName.equals(updatePluginName)) continue;
|
|
|
|
+ if (!FileUtil.copy(updateFile, file)) continue;
|
|
|
|
+ File newName = new File(file.getParentFile(), updateFile.getName());
|
|
|
|
+ file.renameTo(newName);
|
|
|
|
+ updateFile.delete();
|
|
|
|
+ return newName;
|
|
|
|
+ }
|
|
|
|
+ }
|
|
|
|
+ catch (InvalidDescriptionException e) {
|
|
|
|
+ throw new InvalidPluginException(e);
|
Ignore invalid jars inside of the updates folder (Fixes #7751)
This really needs a deeper look here, the way updates are handled is
fairly immature, but, this wasn't ever intended to be a large scale thing
Ideally, imho, we'd collect the list of update files into some form of Map,
that way we just have a reference of Name > File refs, and can filter out
cases where there are two versions of a plugin in there and warn expectidely,
but, that creates some complications, you would need to fall back to a dir
scan in the case of a plugin calling loadPlugin, but, it would at least
give us more defined behavior, as well as improve performance here vs
repeatidely trying to deserialise the plugin.yml defs for every file
in there on every load
2022-04-20 11:00:50 +02:00
|
|
|
}
|
2022-04-18 18:12:39 +02:00
|
|
|
+ return file;
|
|
|
|
+ }
|
|
|
|
|
|
|
|
- File updateFile = new File(updateDirectory, file.getName());
|
|
|
|
- if (updateFile.isFile() && FileUtil.copy(updateFile, file)) {
|
|
|
|
- updateFile.delete();
|
|
|
|
+ @Nullable
|
|
|
|
+ private PluginLoader getPluginLoader(File file) {
|
|
|
|
+ Set<Pattern> filters = fileAssociations.keySet();
|
|
|
|
+ for (Pattern filter : filters) {
|
|
|
|
+ Matcher match = filter.matcher(file.getName());
|
|
|
|
+ if (match.find()) {
|
|
|
|
+ return fileAssociations.get(filter);
|
|
|
|
+ }
|
|
|
|
}
|
|
|
|
+ return null;
|
|
|
|
}
|
|
|
|
+ // Paper end
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Checks if the given plugin is loaded and returns it when applicable
|