Skip to content
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

Open
wants to merge 6 commits into
base: dev/dev
Choose a base branch
from
Open

Paper CommandAPI #517

wants to merge 6 commits into from

Conversation

DerEchtePilz
Copy link
Collaborator

@DerEchtePilz DerEchtePilz commented Jan 19, 2024

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) and commandapi-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:

  • Potentially come up with API to make use of Paper's Brigadier API. That would include:
    • No namespace handling for commands like these
    • Automatic plugin association
    • Probably would require changes to how commands are built or separate API that would make this easier
  • Update build script
  • Remove PaperImplementations.java
  • Work through CommandAPIBukkit and implement in CommandAPIPaper and CommandAPISpigot respectively.
  • Add Kotlin modules for Spigot and Paper (Component related arguments)
  • Make commandapi-annotations platform specific (Component related arguments)
  • Update documentation code to include at least a platform that provides component related arguments
  • Update tests to use CommandAPIPaper or CommandAPISpigot. Maybe even both, share tests and implement component related arguments for both platforms Nope, 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.
  • Update Velocity, apparently
  • Deal with The CommandAPI should use MinecraftServer#getCommands instead of MinecraftServer.vanillaCommandDispatcher #406 for the Paper-specific version
  • Make sure the minecraft namespace exists for commands on Paper
  • Documentation and changelog
  • Test Minecraft versions with the plugin only, shade version and non-shade version:
    • 1.16.5
    • 1.17
    • 1.17.1
    • 1.18, 1.18.1
    • 1.18.2
    • 1.19
    • 1.19.1, 1.19.2
    • 1.19.3
    • 1.19.4
    • 1.20, 1.20.1
    • 1.20.2
    • 1.20.3/4
    • 1.20.5/6 (On Paper, use the CommandAPI using commandapi-paper-shade-mojang-mapped)
    • 1.21 (On Paper, use the CommandAPI using commandapi-paper-shade-mojang-mapped)

@DerEchtePilz DerEchtePilz mentioned this pull request Jan 19, 2024
2 tasks
@DerEchtePilz DerEchtePilz force-pushed the dev/commandapi-paper branch 2 times, most recently from 46558a5 to 9babcd2 Compare February 9, 2024 20:48
@DerEchtePilz DerEchtePilz linked an issue Mar 30, 2024 that may be closed by this pull request
@DerEchtePilz DerEchtePilz force-pushed the dev/commandapi-paper branch 2 times, most recently from b088d05 to a93af70 Compare April 11, 2024 15:10
@DerEchtePilz DerEchtePilz force-pushed the dev/commandapi-paper branch 5 times, most recently from 18e8c28 to f80d789 Compare May 7, 2024 18:49
DerEchtePilz added a commit that referenced this pull request May 12, 2024
+ 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
@DerEchtePilz DerEchtePilz force-pushed the dev/commandapi-paper branch 7 times, most recently from f9a99ef to c357912 Compare May 14, 2024 13:17
@DerEchtePilz DerEchtePilz force-pushed the dev/commandapi-paper branch 3 times, most recently from b152dbe to 4625a32 Compare July 24, 2024 15:49
@DerEchtePilz DerEchtePilz marked this pull request as ready for review July 24, 2024 16:37
Copy link
Collaborator

@willkroboth willkroboth left a 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.

@DerEchtePilz
Copy link
Collaborator Author

About your comment, yeah definitely weird at some places.
The main goal was to share as much code as possible while changing inheritances around.
For example, the methods you linked to in the first link are all defined in CommandAPIPlatform but as CommandAPIBukkit is not a CommandAPIPlatform anymore, I left the methods there so CommandAPIPaper and CommandAPISpigot can call these methods.
The wrapCommandSender method is another case of this weird "needs to be implemented platform specific but also needs to be accessible from CommandAPIBukkit" state since the Bukkit NMS classes call this method.
Definitely let me know if you come up with a way to handle this better/different, but this definitely accomplishes the goal of making the Bukkit modules an interface for the core NMS features and implementations.

@DerEchtePilz DerEchtePilz force-pushed the dev/commandapi-paper branch 4 times, most recently from fce7eba to b049854 Compare July 26, 2024 14:09
willkroboth added a commit that referenced this pull request Jul 31, 2024
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
@DerEchtePilz DerEchtePilz force-pushed the dev/commandapi-paper branch 6 times, most recently from ffa8138 to c85f8a7 Compare August 9, 2024 06:27
Comment on lines -57 to -68
<executions>
<execution>
<goals>
<goal>testCompile</goal>
</goals>
<configuration>
<annotationProcessors>
<annotationProcessor>dev.jorel.commandapi.annotations.Annotations</annotationProcessor>
</annotationProcessors>
</configuration>
</execution>
</executions>
Copy link
Collaborator

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
Copy link
Collaborator

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);
Copy link
Collaborator

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
Copy link
Collaborator

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.

Copy link
Collaborator Author

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) {
Copy link
Collaborator

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.

Comment on lines +76 to +78

@Override
public abstract T instance();
Copy link
Collaborator

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.

Suggested change
@Override
public abstract T instance();

Comment on lines +25 to +29

@Override
public NMS<?> bukkitNMS() {
return null;
}
Copy link
Collaborator

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.

Suggested change
@Override
public NMS<?> bukkitNMS() {
return null;
}


@SuppressWarnings("unchecked")
public static <Source> CommandAPISpigot<Source> getSpigot() {
return (CommandAPISpigot<Source>) spigot;
Copy link
Collaborator

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();
Copy link
Collaborator

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.

Suggested change
onLoad();
super.onLoad();

Comment on lines +13 to +14
@Override
public abstract BaseComponent[] getChat(CommandContext<CommandSourceStack> cmdCtx, String key) throws CommandSyntaxException;
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants