This update improves the structure of the API, the way registries are handled, and introduces a new system for plugin compatibility.
For CustomCrafting users!
Only CustomCrafting v2.16.6+ is compatible!
This version is not backwards compatible with CustomCrafting due to the breaking changes listed below.
Breaking changes
It is mostly backwards compatible, but there are some parts, that if they were used before will break.
Jackson library
WolfyUtilities no longer uses the shaded version of Jackson! Instead, it makes use of the libraries feature in the plugin.yml by Spigot to load the original artifacts and use the correct class paths!
If you made use of these libraries, you need to migrate to the original Jackson dependency and add it to your dependencies besides WolfyUtilities.
APIReferences
APIReferences that are dependent on other plugins (ItemsAdderRef, MagicRef, MMOItemsRef, OraxenRef) were moved to me.wolfyscript.utilities.compatibility.plugins and are from now on interfaces with few or no methods.
API changes
To interface with the API, you should use the core maven artifact from now on.
Code (Text):
<dependencies>
<dependency>
<groupId>com.wolfyscript.wolfyutilities</groupId>
<artifactId>core</artifactId>
<version>2.16.0.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
To get an instance of the API (
WolfyUtilities) you use the new
WolfyUtilCore class.
WolfyUtilCore.getInstance().getAPI(plugin);
Once you have your API instance, it is recommended to use the WolfyUtilities#getCore() instead of the static WolfyUtilCore#getInstance() whenever possible. This makes sure that you follow a well-structured design, instead of referencing static instances everywhere. That means you should pass your API instance to other Objects (like listeners, handlers, etc.) via the constructors.
Registry
If you wanted to register custom objects in previous versions, you had to do that via static constants in the Registry interface, and for registering classes another interface… Not only was this system confusing, but the constants in the interfaces itself made it really confusing when implementing them.
Because of this, the registry interfaces and classes have been redone and the new
Registries class combines all registries into one.
First, the new registry classes have their own package me.wolfyscript.utilities.registry.
The Registry itself got a new hierachy:
- IRegistry
- TypeRegistry - Used to register types, from which objects can be created, serialized, deserialized, etc.
- TypeRegistrySimple - Simple implementation of the TypeRegistry.
- Registry - Used to register objects.
- RegistrySimple - Simple implementation of the Registry.
All registries can be accessed via the
Registries instance:
Registries registries = yourAPIInstance.getRegistries();
or via a static reference:
Registries registries = WolfyUtilCore.getInstance().getRegistries();
Even though the new registry structure is backwards compatible, it is highly recommended that you update to the non-static registries!
Plugin Compatibility
Plugin implementations are split into separate modules now.
That means that only the specific module requires the dependencies of the corresponding plugin.
Additionally, those modules can be removed from the building process, if necessary.
Module structure:
- wolfyutilities-parent [pom]
- core [jar] - The core features, including the API, etc.
- nmsutil [pom]
- nmsutil-v<mc_version> [jar]
- nmsutil-artifact [jar] - Combines all available "nmsutil-v" modules.
- plugin-compatibility-module [pom]
- <plugin_name> [jar]
- plugin-compatibility-artifact [jar] - Combines all available plugin modules.
- wolfyutilities [jar] - Combines all artifacts (core, nmsutil-artifact, plugin-compatibility-artifact) from above, producing the plugin jar.
The main purpose of this new system is to make sure that plugins that WolfyUtilities depends on are all done with loading their data before any process tries to access that data.
This is quite important as some plugins might load their data asynchronously.
To make this system work, WolfyUtilities will look for all available plugins, for which it can find a
PluginIntegration.
Once a plugin is enabled, WolfyUtilities will create a new instance of the corresponding
PluginIntegration and initialize it.
That way, there is one
PluginIntegration per plugin, that acts as an API layer between the plugin dependent module and core.
At this point, the system needs to take async loading into account. Each
PluginIntegration has a method to check if the corresponding plugin is done loading (PluginIntegration#isDoneLoading()).
When a plugin is done loading, its integration will be marked as done. Once all
PluginIntegrations are done, the DependenciesLoadedEvent is being called to notify other plugins.
Getting the PluginIntegrations
All the necessary methods are available via the
Plugins instance.
Code (Java):
Plugins plugins
= yourAPIInstance.
getCore
(
).
getCompatibilityManager
(
).
getPlugins
(
)
;
//or via a static reference:
Plugins plugins
= WolfyUtilCore.
getInstance
(
).
getCompatibilityManager
(
).
getPlugins
(
)
;
There are quite a few methods to get PluginIntegrations and/or run callbacks, etc.
Version number update
To better represent the compatibility of the plugin with Minecraft and other plugins, the version number was changed.
<MAJOR>.<MC>.<MINOR>.<PATCH>
The numbers represent the following:
- MAJOR - These updates contain breaking changes and are most of the time major rewrites.
- MC Compatibility - The lowest compatible Minecraft version without MCs major version, e.g. 1.16 → 16, 1.17 → 17
- MINOR - New features and functionality without breaking backwards compatibility.
- PATCH - Bug fixes with backwards compatibility.
Bug Fixes
- Fixed ParticleContent backwards compatibility
- Fixed - CustomItem#checkOldMetaSettings field is included in serialized json.
- Fixed - WUVersion#parse doesn't work if the version has something appended with "-".
- Fixed - PlayerUtils crash the plugin if it fails to load a player .store file.
- Various minor bug fixes.