v3 Config System - Jake-Moore/KamiCommon GitHub Wiki

❗ This Documentation is Outdated! It is recommended to use v4 with its documentation instead.

See V4 Getting Started for more information.

⚠️ Usage ⚠️

The configuration system is available as both standalone and spigot implementations.
The standalone-utils module contains the standalone implementations like StandaloneConfig, while the spigot-utils module contains spigot-specific implementations like KamiConfig.
The difference is that spigot implementations load default configs from the plugin resources, while standalone implementations load from the jar resources.

Abstraction

Both the standalone and spigot implementations use the same abstract classes and interfaces to ensure consistency, as such using a KamiConfig should be no different from using a StandaloneConfig.
The only differences are KamiConfig has spigot-specific methods like setItemStack.

YAML Support

The configurations system in KamiCommon uses snakeyaml which means it supports YAML 1.1

Comments

The configuration system has had additional support added for comment preservation from plugin resource files.
This means that you can add comments in your plugin's resource file and they will be preserved and copied into the current server-side config.

Comment Inclusion Behavior

  • By default, comments in your resource file are considered a priority and will overwrite any commands in the same section on the server-side config.
    • You may disable this behavior using the field in AbstractConfig called defaultCommentsOverwrite.
  • Special care has been taken to ensure that server-side comments attached to unique yaml keys are also preserved. Admins can write their own comments where no comments exist and they will be preserved.

Parity with Bukkit Configs

The configuration system has been designed to be as similar to Bukkit's YamlConfiguration as possible.
This means that most of the same methods for getting and setting types are available in the config, including some ItemStack methods in KamiConfig.
The hope is that KamiConfig can be a drop-in replacement for most Bukkit plugins using traditional YamlConfiguration classes.

Creating a Config (Spigot)

Note: by default KamiPlugin now creates the config.yml configuration for you. This is a KamiConfig object and can be accessed via KamiPlugin#getKamiConfig().

  • The old JavaPlugin#getConfig() remains the same and uses bukkit behavior and classes.
  • You can override KamiPlugin#loadKamiConfig() and return false to prevent the config.yml file from being loaded automatically.

Adding Secondary Configs

A secondary config can be added using the constructors of KamiConfig.

// The constructor requires the plugin, the file for this config, and whether to copy defaults into the server-side file.
KamiConfig lang = new KamiConfig(this, new File(getDataFolder(), "lang.yml"), true);

// Note: For the spigot implementation, defaults are automatically loaded from the plugin resource stream of a file with the same name as the config.
// To supply a different source for defaults, you can use a different constructor
// Where supplier is your Supplier<InputStream> for the defaults file.
KamiConfig txt = new KamiConfig(this, new File(getDataFolder(), "config.yml"), true, supplier);

Saving and Reloading

Dedicated methods exist in the configs for saving and reloading the config. These are:

// Saves current yaml data to the file.
KamiConfig config = kamiPlugin.getKamiConfig();
config.save();
// Reloads the yaml data from the file, overwriting existing data.
KamiConfig config = kamiPlugin.getKamiConfig();
config.reload();
⚠️ **GitHub.com Fallback** ⚠️