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
* Upgrade japicmp-maven-plugin to 0.15.2
* Do not use deprecated for removal Long constructor
* Update Spring to 5.3.3
* Upgrade Lombok to 1.18.16 + add lombok-mapstruct-binding
Doing this would make sure that starting from Spring Boot 2.4 the mapstruct-processor will not be included in the fat jar produced by the Spring Boot maven plugin if people have it as a maven provided dependency.
This is an alternative if people are not using the maven-compiler-plugin annotationProcessorPaths
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
Upgrades:
* Maven Enforcer Plugin to 3.0.0-M3
* Maven Surefire Plugin to 3.0.0-M5
* Maven Checkstyle Plugin to 3.1.1
* Maven Bundle Plugin to 5.1.1
* Jacoco Maven Plugin to 0.8.6
* Checkstyle to 8.36.1
* JUnit Jipiter to 5.7.0
* AssertJ to 3.17.2
* Guava to 29.0-jre
Fix AssertJ breaking changes
Use Java 8 or Apache Commons IO instead of Guava where possible
Update GitHub Actions to use JDK 14 and JDK 15-ea
