* GetDateTimeFormatterField
** a FieldReference that creates DateTimeFormatters
for given dateFormat as mapper fields
** variableName is created using given dateFormat
* AbstractJavaTimeToStringConversion
provides GetDateTimeFormatterField as required helper field
using DateTimeFormatter instances provided as mapper fields
by GetDateTimeFormatterField
* ConversionProvider
might provide supporting fields directly
* Refactoring
moved/renamed BuiltInFieldReference, BuiltInConstuctorFragment to
package model/common
* MappingBuilderContext provides access to mapper support fields
(that are independent of mapper methods)
* MappingResolverImpl / MapperCreationProcessor
process supporting fields provided by ConversionProvider
* HelperMethod
** extended to supply additional template parameters to
be more flexible in freemarker templates
** extended to support mapper field reference / constructor fragment
* SupportingMappingMethod
** provide templateParameters to freemarker
** hashCode/equals base on name property instead of template name,
as we use one specific template multiple times with different
parameters generating multiple methods
** #getSafeField extracted to SupportingField
* SupportingField
** removed hashCode/equals based on template name,
as we use one specific template multiple times with different
parameters generating multiple methods
(superclass equals/hashcode is fine for that)
** added support for template parameters to be more flexible when
compiling templates
* Tests to verify DateTimeFormatter instance field creation
When the Iterable type we are mapping is not generic
(i.e. it is a custom type extending an Iterable) then the source element type
which is included in the loop was not imported.
This allows to easily avoid the runtime dependency on mapstruct.jar:
we can avoid Mappers.getMapper(...) for instantiating used mappers if
the code follows the conventional pattern for creating mapper singletons.
Co-authored-by: GIBOU Damien <damien.gibou@biomerieux.com>
With this change we are relaxing the error handling when qualifiers are used in `@Mapping`
and we allow defining qualifiers for collections / array mapping to mean the same as if it was defined on `@IterableMapping`
i.e. apply the qualifier on the element mapping
Make sure that MappingReferences are taken into consideration when comparing whether 2 mapping methods are equal.
This makes sure that when using nested target mappings that have the same property mappings, but different mappings 2 distinct methods will be created
When having multiple source properties and only target is defined then the same rules should be applied as if there was no mapping:
* First we check for a matching property in any of the source type
* Second we check if the parameter name matches
Starting from IntelliJ 2020.3 (Build 203.4203.26) the ProcessingEnvironment is wrapped in a Proxy class by IntelliJ.
MapStruct should gracefully handle that and not throw an NPE.
Additionally, we should do best effort to put the used compiler in the generated annotation info
