feat: Dynamic registration with KSP

[MukjepScarlet]

Idea by @ccetl
Discontinued one: #3883

• Event types
• Modules
• Commands
• Fix tests

[MukjepScarlet]

GsonBuilder.registerCommonTypeAdapters can also make use of this.

[superblaubeere27]

This costs + 500 lines and it adds confusion for new contributors.

I mean it is kind of cool, but where is the real benefit?

[MukjepScarlet]

We don't need to add the new module/command into the array/list in manager manually.

And in another hand most of Java clients create module singletons with component scan+annotation+reflection, this might make the "freshman" easier to write.

[MukjepScarlet]

@Module(xxxx)
public class ExampleModule extends AbstractModule

[MukjepScarlet]

However, we do not generate code through reflection but at compile time

[MukjepScarlet]

Now it looks like this.

[1zun4]

This costs + 500 lines and it adds confusion for new contributors.

I mean it is kind of cool, but where is the real benefit?

I think so as well. This is way beyond confusing.

[superblaubeere27]

However, we do not generate code through reflection but at compile time

Yes, as I said, it's pretty cool, but I don't see that it is worth the trade off.

A new module/command/event is not added very frequently. And if a new one is added, the effort of actually coding the module is much bigger than adding a line to ModuleManager.kt. I think the current method is even very straightforward to new contributors.

[MukjepScarlet]

But I think it's very useful to events because we already have annotations on every event classes/objects

By the way about 200 of 500 lines are the copyright header - -

[sqlerrorthing]

This costs + 500 lines and it adds confusion for new contributors.

I mean it is kind of cool, but where is the real benefit?

expand the Contribute section with a mini doc of the codebase, how to REGISTER events, modules, naming conventions and some helpful things for new people who wanna contribute and understand the liquidbounce codebase

@MukjepScarlet please do it

[MukjepScarlet]

I can add comments on the annotations to describe what exactly will be generated.

[sqlerrorthing]

but if im a newborn and wanna to create my module. where is i can QUICKLY find. how to register my new module? please. maybe add a doc for ClientModule about how to register it, and for others (commands, etc) the same

[MukjepScarlet]

If you are a new coder you might first see existing modules, or even directly copy one. That's what I did when I was new to a project.

Comments added.

[sqlerrorthing]

you != all

[sqlerrorthing]

👍

[MukjepScarlet]

However, we do not generate code through reflection but at compile time

Yes, as I said, it's pretty cool, but I don't see that it is worth the trade off.

A new module/command/event is not added very frequently. And if a new one is added, the effort of actually coding the module is much bigger than adding a line to ModuleManager.kt. I think the current method is even very straightforward to new contributors.

I think it can be applied to Event classes at least. We already have annotation on each of them.