-
-
Notifications
You must be signed in to change notification settings - Fork 68
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 CommandAPI #517
base: dev/dev
Are you sure you want to change the base?
Paper CommandAPI #517
Conversation
46558a5
to
9babcd2
Compare
9babcd2
to
330f113
Compare
9102ea7
to
bfbe182
Compare
bfbe182
to
c5d49e1
Compare
4dba32a
to
9f28b25
Compare
b088d05
to
a93af70
Compare
18e8c28
to
f80d789
Compare
36ca865
to
acda2d1
Compare
+ fixed exception appearing in server log, this isn't done with VarHandles but I think because this is a hotfix, it is fine for now. I will handle all this properly on dev/commandapi-paper and #517
f9a99ef
to
c357912
Compare
a81dd6b
to
66db468
Compare
b152dbe
to
4625a32
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an initial look at some things.
The hierarchy of Bukkit and Spigot/Paper NMS feels weird to me, though I can't quite say what to do about it. For example, these methods in CommandAPIPaper need to call the static getBukkit
method to get the generics to match up. Implementations of NMS call up CommandAPIBukkit#wrapCommandSender
, which passes it over to BukkitPlatform#wrapCommandSender
. Nothing major, but I just wonder if there is a cleaner way. Maybe I'll do some poking around on my own and see if I find anything.
commandapi-core/src/main/java/dev/jorel/commandapi/CommandAPIPlatform.java
Outdated
Show resolved
Hide resolved
...otlin/commandapi-kotlin-bukkit/src/main/kotlin/dev/jorel/commandapi/kotlindsl/ExecutorDSL.kt
Outdated
Show resolved
Hide resolved
...ndapi-bukkit/commandapi-bukkit-core/src/main/java/dev/jorel/commandapi/CommandAPIBukkit.java
Outdated
Show resolved
Hide resolved
...ms/commandapi-bukkit/commandapi-bukkit-core/src/main/java/dev/jorel/commandapi/Platform.java
Outdated
Show resolved
Hide resolved
About your comment, yeah definitely weird at some places. |
fce7eba
to
b049854
Compare
Less code evident by reduced jar size (`commandapi-paper-plugin` 746.0 kB -> 728.3 kB, `commandapi-spigot-plugin` 813.5 kB -> 789.6 kB, sidenote: why is Spigot so much bigger lol) Tested chat arguments on Spigot and Paper 1.16.5-1.21 to ensure validity CommandAPISpigot and CommandAPIPaper are now interfaces. CommandAPIBukkit/Spigot/Paper all extend/implement BukkitPlatform to establish methods they can use from each other. The Bukkit nms hierarchy is abstract classes. Spigot/Paper nms modules merge the Bukkit NMS class with the Spigot/Paper interface. Preprocessor comments added to clarify some aspects of the structure. pom.xml files combed through to ensure clear and consistent structure and comments. --- Reworked nms pom.xml files so depending on a module propagates its classifier to transitive nms dependencies. E.g. when you depend on `dev.jorel:commandapi-bukkit-1.21:jar:mojang-mapped`, you get `dev.jorel:commandapi-bukkit-nms-common:jar:mojang-mapped`, but when you depend on `dev.jorel:commandapi-bukkit-1.21:jar:` you get `dev.jorel:commandapi-bukkit-nms-common:jar:`. This makes it so transitive dependencies work as expected, and you don't need to redeclare them to get the right classifier. E.g. before, when you depended on when you depend on `dev.jorel:commandapi-bukkit-1.21:jar:`, you would get `dev.jorel:commandapi-bukkit-nms-common:jar:mojang-mapped` in your final jar unless you explicitly added a dependency for `dev.jorel:commandapi-bukkit-nms-common:jar:` that took priority. This was done by getting maven to generate the nms jars like so: - Compile mojang-mapped source files into jar - Shade mojang-mapped dependencies into new jar with mojang-mapped classifier - Remap source files still in default jar to spigot mappings - Shade spigot-mapped dependencies into default jar For reference, the old build process (which is still used if a module does not have any nms dependencies) goes like so: - Compile mojang-mapped source files into jar - Save into new jar with mojang-mapped classifier - Remap source files in default jar to spigot mappings This might have been easier to set up using gradle, but I got it working :P. --- The `CommandAPIBukkit#failWithAdventureComponent` methods were moved to CommandAPIPaper. This was causing a problem, because SpigotNMS implementations that extended CommandAPIBukkit didn't have access to the Component classes since their modules did not include a dependency on paper-api or adventure. `CommandAPIBukkit#failWithBaseComponenet` was moved to CommandAPISpigot to match (which is kinda nice b/c it doesn't say "BaseComponent is deprecated" by paper-api). This means it is no longer possible for a Spigot plugin that shades adventure to access that method (which is perhaps consistent with the chat arguments, but maybe limiting). Alternate solutions that would allow a Spigot plugin to access `failWithAdventureComponent` include adding a paper-api/adventure dependency to the spigot-nms modules or moving the `failWithComponent` methods to a different shared class in bukkit-core. --- TODO: - Ensure preprocessor and brigadier dependencies are not being leaked Further investigation: - Can the load message (e.g. `Loaded platform SpigotNMS_1_16_R3 > NMS_1_16_R3 > CommandAPIBukkit`) be tweaked to include the Spigot/Paper interfaces? - Can the chat preview handler code be merged more? - Should/can Spigot always be spigot-mapped, pre 1.20.5 Paper always be spigot-mapped, and 1.20.5+ Paper always be mojang-mapped? - Should/can there be a plugin and shade dependency that supports Spigot and Paper, like before? - Other things mentioned in added code todos This is kinda code review for #517
ffa8138
to
c85f8a7
Compare
c85f8a7
to
6b8070a
Compare
6b8070a
to
904dc4b
Compare
<executions> | ||
<execution> | ||
<goals> | ||
<goal>testCompile</goal> | ||
</goals> | ||
<configuration> | ||
<annotationProcessors> | ||
<annotationProcessor>dev.jorel.commandapi.annotations.Annotations</annotationProcessor> | ||
</annotationProcessors> | ||
</configuration> | ||
</execution> | ||
</executions> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this build plugin no longer has any executions
, does it need to be declared anymore? Could this removal be expanded to also remove the whole build
section?
@@ -52,13 +52,15 @@ inline fun CommandAPICommand.location2DArgument(nodeName: String, locationType: | |||
inline fun CommandAPICommand.rotationArgument(nodeName: String, optional: Boolean = false, block: Argument<*>.() -> Unit = {}): CommandAPICommand = withArguments(RotationArgument(nodeName).setOptional(optional).apply(block)) | |||
inline fun CommandAPICommand.axisArgument(nodeName: String, optional: Boolean = false, block: Argument<*>.() -> Unit = {}): CommandAPICommand = withArguments(AxisArgument(nodeName).setOptional(optional).apply(block)) | |||
|
|||
/* TODO: Create additional modules for component related arguments |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this TODO (and others with the same comment) were resolved, so this commented-out code can probably be removed now.
|
||
@Override | ||
default void onLoad(CommandAPIConfig<?> config) { | ||
onLoad((CommandAPIBukkitConfig<?>) config); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there be a config instanceof CommandAPIBukkitConfig
check here before doing the cast, like there is in other classes where a general config object is being loaded by a specific platform? Alternatively, CommandAPISpigot/Paper are already checking the class. So, this method could be removed, and Spigot/Paper would just start from a CommandAPIConfig.
@Unimplemented(because = REQUIRES_MINECRAFT_SERVER) | ||
public abstract SuggestionProvider<Source> getSuggestionProvider(SuggestionProviders suggestionProvider); | ||
|
||
@Override |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like many of the methods in CommandAPIBukkit
incorrectly had their @Override
annotation removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably a remnant from when CommandAPIBukkit
wasn't a CommandAPIPlatform
@Override | ||
public CommandAPIBukkitConfig instance() { | ||
return this; | ||
public T skipReloadDatapacks(boolean skip) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method seems to have lost its javadocs when it was moved down from further up in the class.
|
||
@Override | ||
public abstract T instance(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this method declaration does anything. It can be removed.
@Override | |
public abstract T instance(); |
...mmandapi-spigot/commandapi-spigot-core/src/main/java/dev/jorel/commandapi/nms/SpigotNMS.java
Show resolved
Hide resolved
|
||
@Override | ||
public NMS<?> bukkitNMS() { | ||
return null; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems odd. This probably shouldn't return null
. This method declaration should probably be removed so it can just be inherited normally in the subclasses.
@Override | |
public NMS<?> bukkitNMS() { | |
return null; | |
} |
|
||
@SuppressWarnings("unchecked") | ||
public static <Source> CommandAPISpigot<Source> getSpigot() { | ||
return (CommandAPISpigot<Source>) spigot; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this have a hey, you're calling this too early
check like there is in CommandAPIBukkit
?
CommandAPI.logError("CommandAPIBukkit was loaded with non-Bukkit config!"); | ||
CommandAPI.logError("Attempts to access Bukkit-specific config variables will fail!"); | ||
} | ||
onLoad(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be clearer this calls the method in CommandAPIBukkit
if it used the super
keyword. At the moment, I was like, "Wait, where's the no-parameter onLoad
method in CommandAPISpigot
?" when I saw this.
onLoad(); | |
super.onLoad(); |
@Override | ||
public abstract BaseComponent[] getChat(CommandContext<CommandSourceStack> cmdCtx, String key) throws CommandSyntaxException; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getChat
(and getChatComponent
) could be implemented here, as long as they are @Overriden
in 1.20.5+, since Serializer#toJson
needs the COMMAND_BUILD_CONTEXT
then.
NMS_Common
on dev/dev
and dev/paper/restructure-experiment
currently does this.
This PR refactors parts of the CommandAPI so the Adventure library and Bungee library aren't used in the same .jar's anymore and Paper API and Spigot API also aren't used together anymore.
In order to do that,
commandapi-bukkit-core
only serves as a tool to access NMS so it can be shared and doesn't have to be implemented again for Paper and Spigot.The new usable platforms are
commandapi-paper-(core/shade/plugin)
andcommandapi-spigot-(core/shade/plugin)
.This still requires a lot of work. I am fairly confident that these changes should already make a fairly functional CommandAPI for Paper and Spigot, however, there still is a lot of work left.
This should also invalidate #474 as this refactor puts them into different modules
TODO's:
PaperImplementations.java
CommandAPIBukkit
and implement inCommandAPIPaper
andCommandAPISpigot
respectively.commandapi-annotations
platform specific (Component related arguments)Update tests to useNope, cancelling those. The original tests are still present but they won't work. After trying to port tests two times I do not really know what to do so if someone else at some point, possibly after this is merged, has an idea this could and should be implemented.CommandAPIPaper
orCommandAPISpigot
. Maybe even both, share tests and implement component related arguments for both platformsminecraft
namespace exists for commands on Papercommandapi-paper-shade-mojang-mapped
)commandapi-paper-shade-mojang-mapped
)