Entrypoint package inconsistenies (PreLaunch vs ModInitializer)

[i509VCB]

I noticed that there seems to be some inconsistency with the fact the PreLaunchEntrypoint is located in the net.fabricmc.loader.api.entrypoint package.

The ClientModInitializer/DedicatedServerModInitializer/ModInitializer are inside the net.fabricmc.api package. I feel we should be consistent and move these initializers to the same package as pre launch.

Talks on discord did conclude that most use cases of ClientModInitializer could be deprecated without breaking binary compatibility if we were to implement as follows:

net.fabricmc.api.ClientModInitializer extends net.fabricmc.loader.api.entrypoint.ClientModInitializer

However if anyone calls FabricLoader.getEntrypointContainers("client", ClientModInitializer.class), there will be mods which break. The only case I can think of is Informed load which does that.

Also I noticed that we use entrypoint suffix for the PreLaunchEntrypoint but the initializer names exist. Maybe consider these renames:

ClientModInitializer -> ClientModEntrypoint ModInitializer -> ModEntrypoint DedicatedServerModInitializer -> DedicatedServerModEntrypoint

The renames would help distinguish between the old and new interfaces more easily. (Even though deprecation would already be blaring at you). But aren't required (I'd like them for consistency).

[liach]

Imo we indeed should move them to a loader.api.entrypoint pacakage.

If people are really concerned with class renaming, we can just handle that with a custom classloader if things go into hell.

[Juuxel]

I think the current class names are fine, and they describe what the initialisers are meant for better than just "x entrypoint". With the proposed ones, there can be some confusion especially with ModEntrypoint since all entrypoints are mod entrypoints.

[i509VCB]

class names seem fine otherwise. would like the nicer package though.