MapStruct should not use types that are outside of java.base.
This makes sure that no additional dependencies (such as jaxb-api) are needed on the annotation processor path
Remove the org.jboss.apiviz.APIviz doclet since it is no longer compatible with Java 11.
Add new group in the Javadoc for the MapStruct Processor SPI
Fix Javadoc warnings
* 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
