New rules:
1. Constructor annotated with @Default (from any package) has highest precedence
2. If there is a single public constructor then it would be used to construct the object
3. If a parameterless constructor exists then it would be used to construct the object, and the other constructors will be ignored
Add a new EnumNamingStrategy SPI which can be used for customising the way enums are matched by name.
It is similar to the AccessorNamingStrategy such that it allows implementors to provide a custom way of defining a property.
Related to #796, #1220, #1789 and #1667
Add a new custom EnumTransformationStrategy SPI which can be used for providing custom way of name based mapping for enums.
Add 4 out of the box transformation strategies:
* prefix - add a prefix to the name based enum mapping
* stripPrefix - remove a prefix from the name based enum mapping
* suffix - add a suffix to the name based enum mapping
* stripSuffix - remove a suffix from the name based enum mapping
This can be achieved by using the new `EnumMapping`
e.g.
Add suffix `_TYPE` to all enums:
`@EnumMapping(nameTransformationStrategy = "suffix", configuration = "_TYPE")`
With this it would be possible to achieve what is needed in #796, #1220, #1789.
For some reason when using annotationProcessorPaths IntelliJ includes the provided and test scoped dependencies on the annotation processor paths.
With this change there would be no test dependencies that IntelliJ can add.
By default the constructor argument names are used to extract the target properties.
If a constructor is annotated with an annotation named `@ConstructorProperties` (from any package) then it would be used to extract the target properties.
If a mapping target has a parameterless empty constructor it would be used to instantiate the target.
When there are multiple constructors then an annotation named `@Default` (from any package) can be used to mark a constructor that should be used by default when instantiating the target.
Supports mapping into Java 14 Records and Kotlin data classes out of the box
Due to a bug in javac (JDK-8229535) for an annotation with Class values, instead of returning a TypeMirror with TypeKind#ERROR the compiler returns the string "<error>". Eclipse doesn't have this problem currently.
Disable one test in GenericsHierarchyTest for Eclipse on Java 8 due to a bug in the Tycho compiler.
Disable freeBuilder integration test for Eclipse since there are some problems in the second round of annotation processing (no ModelElementProcessor(s) are found)
We need to treat the import of the decoratorType specially when it is nested.
Calling addIfImportRequired is not the most correct approach since it would
lead to checking if the type is to be imported and that would be false
since the Decorator is a nested class within the Mapper.
However, when generating the Decorator this is not needed, because the Decorator is a top level class itself
In a nutshell creating the Decorator should have its own ProcessorContext, but it doesn't
