Migrating from 1.x to 2.x

❗	ConfigMe 2.0 is still in development, so this document is just an ongoing draft!

Property type changes

• PrimitivePropertyType has been split to BooleanType, NumberType and StringType
• Note: Strings are now converted to booleans/numbers if the representation matches, e.g. if String("4") is read from a property resource for an int property, its value will be determined to be the integer 4. ConfigMe 1.x discarded String values for all boolean and number types.
• Note: if a conversion fails for an element inside an array, list or similar, ConfigMe will consider the resource not to be "fully valid" in more cases than before. This means that the configuration file will be resaved in more scenarios than previously if you are using a migration service. This change makes the behavior more consistent and should not affect you; however, please don't hesitate to open an issue if you need clarifications.

Other changes

• Utils is renamed to FileUtils. Feel free to use the method(s) in FileUtils—it is part of the public API.
• Constructor arguments in Property classes always start with the String path, then a type (if applicable), and the default value at the end. Some constructors have been changed to follow this order (e.g. TypeBasedProperty).

Bean mapper

General changes in Mapper (underlying converter of BeanProperty):

• Getters and setters on bean classes are no longer relevant. The class's fields are taken as properties.
  • Consequently, @ExportName can only be set on fields.
  • To make ConfigMe ignore a field, declare it as transient or add the new annotation @IgnoreInMapping.
  • The annotation java.beans.Transient is no longer supported. Use ConfigMe's @IgnoreInMapping instead.
• Note that, as with regular properties, more conversions are now possible, e.g. a string "3" will be converted to the integer 3 for an int field.
• Java records can now also be used as bean property types. (This is not recommended.)

You can skip all the following mapper subsections if you don't override Mapper or any of its components.

Leaf value handlers

If you don't override any Mapper behavior, you can skip this section.

• LeafValueHandler has been split into LeafValueHandler and MapperLeafType. To support custom types in the bean mapper, you've had to implement your own LeafValueHandler. This is now being handled by a MapperLeafType. LeafValueHandler combines multiple MapperLeafType implementations. Previously, LeafValueHandler was doing both things via the same interface.
• All default LeafValueHandler implementations that handled a specific type have changed and are mostly merged with the PropertyType implementations.
  • For example: BooleanLeafValueHandler (old) -> BooleanType (new); NumberLeafValueHandler (old) -> NumberType (new).

TODO old/new code samples

Bean definitions

If you don't override any Mapper behavior, you can skip this section.

In ConfigMe 1, the mapper calls BeanDescriptionFactory to get a bean's properties. In ConfigMe 2, the mapper uses a BeanDefinitionService to get a BeanDefinition object. The definition object collects bean properties from a BeanPropertyExtractor.

In general, the package ch.jalu.configme.beanmapper.propertydescription has been renamed to ch.jalu.configme.beanmapper.definition.properties. Noteworthy classes involved in the introspection of a bean are the following:

Old name (ConfigMe 1)	New name (ConfigMe 2)	Description
c.j.c.b.propertydescription.BeanPropertyDescription	c.j.c.b.definition.properties.BeanPropertyDefinition	Info about one property
c.j.c.b.propertydescription.BeanDescriptionFactory	c.j.c.b..definition.properties.BeanPropertyExtractor	Returns bean property definitions
—	c.j.c.b..definition.BeanDefinition	Description of a bean (e.g. how to create it)
—	c.j.c.b..definition.BeanDefinitionService	Provides bean definitions. Called by the mapper.

Misc

If you don't override any Mapper behavior, you can skip this section.

• Moved MappingContext to package configme.beanmapper.context
• TypeInformation is no longer provided by ConfigMe, but it now uses TypeInfo from the library ch.jalu.typeresolver

Property builders

The property builder implementations have been split and the methods for setting the default value have been changed as to be consistent:

• A method defaultValue will always set the entire default value (e.g. whole default list of a list property) and may only be used once. Use addToDefaultValue to successively add default entries to a list/set/map/array property.
• The property builder classes have changed. This should not greatly affect you if you are using the builder methods from PropertyInitializer. PropertyBuilder has been split into classes in the ch.jalu.configme.properties.builder package.
  • Old PropertyBuilder.ListPropertyBuilder is now CollectionPropertyBuilder#listBuilder
  • Old PropertyBuilder.SetPropertyBuilder is now CollectionPropertyBuilder#setBuilder
  • Old PropertyBuilder.ArrayPropertyBuilder is now ArrayPropertyBuilder#arrayBuilder
  • Old PropertyBuilder.InlineArrayPropertyBuilder is now ArrayPropertyBuilder#inlineArrayBuilder
  • Old PropertyBuilder.MapPropertyBuilder is now MapPropertyBuilder
  • Old PropertyBuilder.TypeBasedPropertyBuilder has been removed (along with PropertyInitializer#typeBasedProperty). Do you need this? Please open a new GitHub issue if so.

TODO add old/new examples

Inline array property type

• InlineArrayConverter and StandardInlineArrayConverters have been merged and renamed to InlineArrayPropertyType. The class no longer is a separate type, but rather it implements PropertyType.
• TODO specify string behavior (#382)

TODO add old/new examples