Migrating from 0.x to 1.x

Creating settings manager

Previously the SettingsManager had a public constructor and other helper methods, now a builder SettingsManagerBuilder exists to get instances from.

Old:

        SettingsManager settingsManager = new SettingsManager(
            myPropertyResource, myMigrationService, CommandSettings.class, DelaySettings.class);

New:

        SettingsManager settingsManager = SettingsManagerBuilder
            .withResource(myPropertyResource)
            .configurationData(CommandSettings.class, DelaySettings.class)
            .migrationService(myMigrationService)
            .create();

Renamings / interfaces

Many classes now have their own interface (e.g. SettingsManager, Mapper, ConfigurationData). Typically a builder class or a standard -Impl class exists to get instances of those types.

Among others, note also that Property#getValue(PropertyResource) is now Property#determineValue(PropertyReader), and ConfigurationDataBuilder#collectData has been renamed to createConfiguration.

Export value

TBD. ⚠️

Property resource / Configuration data

In ConfigMe 0.x, the property resource kept track of all properties' values. Configuration data contained a list of all known properties and associated comments. Now, in ConfigMe 1.x, the property resource is only responsible for delivering a read-only property reader (file reader) and for exporting the values—the values of the properties are being managed by ConfigurationData.

Property reader is no longer refreshable (for a newer state of the file a new reader should be retrieved from the property resource). Typically these changes are enough behind the scenes that they don't affect you directly. However, as a consequence, the migration service interface has changed. See the next section for more details.

Migration service

Since the property resource no longer manages the property's values, while migrating you can set the value of a property to the configuration data instance instead.

Old:

    @Override
    public boolean checkAndMigrate(PropertyResource resource, List<Property<?>> properties) {
        if (someCheck()) {
            resource.setValue("property", new Value());
            return true;
        }
        return false;
    }

New:

    @Override
    public boolean checkAndMigrate(PropertyReader reader, ConfigurationData configurationData) {
        if (someCheck()) {
            Property<Value> property = SettingsHolderImpl.VALUE_PROP;
            configurationData.setValue(property, new Value());
            return true;
        }
        return false;
    }

TL;DR now you read from property reader and you write to configuration data.

Lowercase String List property now lowercase String Set property

The property type Property<List<String>> which had all its entries in lowercase has been changed to a Set: Property<Set<String>>. The reason is that Set has a more efficient #contains method, which is what this property type is typically used for.

Old:

import static ch.jalu.configme.properties.PropertyInitializer.newLowercaseListProperty;

    public static final Property<List<String>> FORBIDDEN_NAMES =
        newLowercaseListProperty("blacklist.names", "test", "potato");

New:

import static ch.jalu.configme.properties.PropertyInitializer.newLowercaseStringSetProperty;

    public static final Property<Set<String>> FORBIDDEN_NAMES =
        newLowercaseStringSetProperty("blacklist.names", "test", "potato");

Section comments

Annotation @SectionComments has been replaced with a method on SettingsHolder which can be extended to register comments.

Old:

    @SectionComments
    public static Map<String, String[]> buildSectionComments() {
        return ImmutableMap.of("Converter", new String[]{"Converter settings"});
    }

New:

    @Override
    public void registerComments(CommentsConfiguration conf) {
        conf.setComment("Converter", "Converter settings");
    }