Modules

Full list of JSky modules and how to add them to your project

JSky is a modular project, which means that you can choose what parts of it you want to use or not. Most likely you will end up only using the base module. The purpuse of modules is to reduce your jar size, as some modules such as the yaml module need to shade other libraries to work.

JSky is published on the Codersky Network maven repository. You need to add it. See how here.

JSky modules

Before adding a specific module of JSky to your project, you should know what modules are offered and what are each of them about. The only mandatory module of JSky is the base module. This module is required by every other module in order to work and contains most of the functionality of JSky. On most cases, you will only need to add this module. However, here is the full list:

• base - As previosly mentioned, the base of JSky, required.

• yaml - Provides Yaml file utilities.

About JSky dependencies

Fist of all, the base subproject of JSky will never require any dependency other than Jetbrains Annotations, which are compile only, so they are not shaded. That being said, other subprojects may require dependencies to work. In those cases, there are a few things you should know.

JSky does NOT relocate any of its dependencies. Meaning that they are kept with their original package names and conflicts are possible. Here is the example that caused this decision:

• JSky-yaml shades SnakeYaml (At org.yaml.snakeyaml)

• Spigot also shades SnakeYaml (At org.yaml.snakeyaml)

Previously, org.yaml.snakeyaml was relocated to net.codersky.jsky.shaded.snakeyaml. This avoids the conflict! However, you will notice that now we have a redundant dependency, this can cause another type of conflict where you want to use SnakeYaml directly but now you have it twice. The one shaded by Spigot and the one shaded by JSky, also, the resulting jar will be needlessly bigger. SnakeYaml adds about 300KB, this is also not ideal and leaves us with two possible solutions:

• Don't shade any dependency.

• Shade dependencies with their original package names.

The first option is not ideal, as developers would need to manually add dependencies and using the correct version of them would be a nightmare. So the chosen solution remains, using the original package names. This solution only requires the developer to check if any dependency provided by the module they want to use would conflict with their project. This is easy because here on this guide you will find every dependency used by every module. If there is a conflict, the developer can choose what to do with this conflict without us making the decision.