* Use Java 17 for building MapStruct (still Java 8 compatible)
* Upgrade to Spring 6 for tests
* Adjust excludes and min tests version for some integration tests
Prior to this MapStruct would only use `Elements#getTypeElement`.
With this PR if the mapper being generated is within a module MapStruct will use that module
for the methods that are needed (getTypeElement and getPackageElement).
Adapt the build to require a minimum Java 11 for building the processor module.
Adapt the GitHub actions to properly run integration tests with Java 8
Ignore Java 9 usages for the animal-sniffer-plugin
Support for Jakarta is done in 2 ways:
* current jsr330 component model - In this case Jakarta Inject will be used if javax.inject is not available
* new jakarta component model - In this case Jakarta Inject will always be used
Since the removal of the Eclipse Specific compiler workarounds in c2e803403027f3fae92bd15b0ba50ab7df5063e6
the org.eclipse.tycho:tycho-compiler-jdt dependency is no longer needed in the compile code, we only need it for tests
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.
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
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.
Using optional because IntelliJ is picking up hickory as a transitive
dependency and runs the hickory processor in projects using mapstruct-processor.
This happens only when the processor is defined in the maven-compiler annotationProcessorPaths.
This is related to https://youtrack.jetbrains.com/issue/IDEA-200481.