Update test annotations to be JUnit Jupiter compatible
Replace all Test annotations from tests that are run with the AnnotationProcessorTestRunner with ProcessorTest.
Replace JUnit 4 Test#expected with assertThatThrownBy from AssertJ.
Replace Rule for GeneratedSource with RegisterExtension.
Fix some tests that were not reverting the changes to the default Locale and TimeZone.
Replace usage of org.junit.Assert with equivalent from org.junit.jupiter.api.Assertions or AssertJ.
With JUnit Jupiter it is still not possible to set the ClassLoader for loading the test class.
However, since 5.8 M1 there is a way to hook into the launcher discovery process and change the Current Thread ContextClassLoader which would load the classes with our customer ClassLoader.
Once JUnit Jupiter 201 is resolved we can simplify this.
The CompilationCache is stored in the GlobalCache with the CompilationRequest as key.
This means that even when methods are not executed in some particular order if they have same WithClasses then they would reuse the cache.
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
