Add annotation-based plugin registration

[andriihorpenko]

Description

Description partially taken from my feature request in Discord

Many mods utilize annotation-based registration of their extensions, e.g. EMI @EmiEntrypoint, Jade @WailaPlugin, etc.
KubeJS, on the other hand, uses .txt files with a special syntax.

This PR adds a new @KubeJSEntrypoint annotation. It supports file-based registration features too, e.g. client-only plugin marker and mods required to load a plugin.

NeoForge provides tools for obtaining classes with annotations, and it uses those itself for @Mod and @EventBus discovery.

Note

This PR targets 26.1, but I would very much like to see it on 1.21.1 as well. I can draft a backport PR - should be easy.

Examples

Regular plugin registration

@KubeJSPluginEntrypoint
public class MyPlugin implements KubeJSPlugin {}

Client-side only plugin registration

@KubeJSPluginEntrypoint(clientOnly = true)
public class MyPlugin implements KubeJSPlugin {}

Requiring both JEI and Mekanism mods to be loaded

@KubeJSPluginEntrypoint(requiredMods = {"jei", "mekanism"})
public class MyPlugin implements KubeJSPlugin {}

Other details

• This PR keeps support for file-based plugin registration for backwards compatibility.

[pietro-lopes]

I strongly disagree with annotation based stuff for discovery of entry points, It adds MASSIVE overhead (I'm a modpackdev of packs that contains ~400-500) for no real benefit

Using .txt file you still need to query every pack entry to check if the resource is there, but at least scales better

[andriihorpenko]

I don’t see how that would cause an issue. This is not using a library like org.reflections, which scans an entire package for annotations on demand. This is using existing NeoForge tooling, which provides mods with already scanned annotations data without a second pass. Neo looks for all annotations and stores associated data no matter what, so effectively nothing changes, we just utilize data that is already available.

[monochromem1nd]

I strongly disagree with annotation based stuff for discovery of entry points, It adds MASSIVE overhead (I'm a modpackdev of packs that contains ~400-500) for no real benefit

Using .txt file you still need to query every pack entry to check if the resource is there, but at least scales better

really cringed it up

[rlnt]

really cringed it up

What a really useful contribution to the conversation.

Many mods utilize annotation-based registration of their extensions, e.g. EMI @EmiEntrypoint, Jade @WailaPlugin, etc.
KubeJS, on the other hand, uses .txt files with a special syntax.

Do you have any specific reason to change this behavior apart from "other mods do this"? Or is this what your LLM suggested as a good contribution?

[andriihorpenko]

Do you have any specific reason to change this

Throwing an annotation on a class is much more obvious to developers rather than maintaining a separate plain text file, consisting of FQCNs with cryptic syntax for required mods and client only marker. Plus plain text files remain for backwards compatibility, annotations are opt-in.

Or is this what your LLM suggested as a good contribution?

Not sure how you came up with accusing someone of using LLMs, that’s not nice. No, this is my genuine proposal because I’ve made lots of KubeJS plugins and I saw adding an alternative way to register plugins as a nice addition.