search

Rollczi / LiteCommands

☄️ LiteCommands - Command framework for Velocity, Bukkit, Paper, BungeeCord, Minestom, Sponge, Fabric, JDA and future implementations.
https://docs.rollczi.dev/
Apache License 2.0
146 stars 21 forks source link

Problems and suggestions on dependency management #412

Closed Shinnvy closed 2 months ago

Shinnvy commented 3 months ago

I have been using LiteCommands in my project and noticed a few areas where the dependency management could potentially be optimized. I hope you don't mind me bringing this up, as I believe these optimizations could benefit both LiteCommands and projects that depend on it.

org.jetbrains:annotations

I observed that LiteCommands uses api("org.jetbrains:annotations:24.0.1") in its Gradle build file. This maybe causes org.jetbrains:annotations to be included in the final JAR (I'm not sure), which in turn means that projects depending on LiteCommands also include this dependency. In my case, since my project is built with Maven, I had to manually add org.jetbrains:annotations as a dependency with the compile scope to prevent it from being packaged into a jar.

org.panda-lang:expressible

Additionally, I noticed that LiteCommands only uses a few classes from org.panda-lang:expressible, specifically Lazy, Result, and Option. Since Optioncan be replaced by java.util.Optional, and the other two classes seem to have straightforward implementations, I wonder if there is a specific reason why the entire org.panda-lang:expressible library is included. Evaluate whether the entire org.panda-lang:expressible library is necessary or if the specific classes (Lazy, Result, Option) can be extracted or reimplemented within LiteCommands. This would reduce the dependency footprint and make LiteCommands more lightweight.

Does this mean that, when I use LiteCommands, need to be repeated to add org. Jetbrains: annotations and set to compileto avoid packaging. Also, I need to relocate LiteCommands, panda.std, and net.joda.expiringmap, right? There seems to be no explanation on this in the document. If so, this seems to be something that can be optimized. Will the author consider this? Thank you!

Rollczi commented 3 months ago

Hi @Shinnvy, thanks for your issue.

I observed that LiteCommands uses api("org.jetbrains:annotations:24.0.1") in its Gradle build file. This maybe causes org.jetbrains:annotations to be included in the final JAR (I'm not sure),

Currently litecommands doesn't include any files from own dependencies. You can checkout it by downloading jar from maven repository: https://repo.panda-lang.org/#/releases/dev/rollczi/litecommands-core/3.4.2

But LiteCommands mark required dependencies as compile in related pom file: https://repo.panda-lang.org/releases/dev/rollczi/litecommands-core/3.4.2/litecommands-core-3.4.2.pom

You can exclude jetbrains annotations because it isn't required to runtime.

Since Option can be replaced by java.util.Optional

Option is actually used as an additional feature. In LiteCommands base code I use only java Optional

Evaluate whether the entire org.panda-lang:expressible library is necessary or if the specific classes (Lazy, Result, Option) can be extracted or reimplemented within LiteCommands. This would reduce the dependency footprint and make LiteCommands more lightweight.

You're right, I can remove Result Lazy from code base. I will probably have to create new module with implementation of Option wrapper or remove it.

I need to relocate LiteCommands, panda.std, and net.joda.expiringmap, right?

This depend on your platform e.g. for JDA or plugin paper (with isolated classloader) you don't need relocation, but in other cases you need.

There seems to be no explanation on this in the document.

Unfortunately, LiteCommands doesn't have good docs :/

Shinnvy commented 3 months ago

Hi @Rollczi ! Thank you for your detailed and thorough responses! I now have a clear understanding of the dependency management in LiteCommands. Your explanations have addressed all my questions, and I no longer have any doubts.